EMV 
Integrated Circuit Card 
Specifications for Payment Systems 


Book 3 
Application Specification 


Version 4.3 
November 2011 


EMV” 
Integrated Circuit Card 
Specifications for Payment Systems 


Book 3 
Application Specification 


Version 4.3 
November 2011 


* EMV is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The 
EMV trademark is owned by EMVCo. 


EMV 4.3 Book 3 
Application Specification 


© 2011 EMVCo, LLC (“EMVCo’). All rights reserved. Any and all uses of these Specifications 
are subject to the terms and conditions of the EMVCo Terms of Use agreement available at 
www.emvco.com. These Specifications are provided "AS IS" without warranties of any kind, 
and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in 
these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, 
EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF 
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON- 
INFRINGEMENT, AS TO THESE SPECIFICATIONS. 


EMVCo makes no representations or warranties with respect to intellectual property rights of 
any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to 
determine whether any implementation of these Specifications may violate, infringe, or 
otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other 
intellectual property rights of third parties, and thus any person who implements any part of 
these Specifications should consult an intellectual property attorney before any such 
implementation. 


Without limiting the foregoing, the Specifications may provide for the use of public key 
encryption and other technology, which may be the subject matter of patents in several 
countries. Any party seeking to implement these Specifications is solely responsible for 
determining whether its activities require a license to any such technology, including for 
patents on public key encryption technology. EMVCo shall not be liable under any theory for 
any party's infringement of any intellectual property rights in connection with these 
Specifications. 


Page ii November 2011 


EMV 4.3 Book 3 
Application Specification 


Revision Log - Version 4.3 


The following changes have been made to Book 8 since the publication of 
Version 4.2. Numbering and cross references in this version have been updated to 
reflect changes introduced by the published bulletins. 
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1 Scope 


This document, the Integrated Circuit Card Specifications for Payment Systems - 
Book 8, Application Specification defines the terminal and integrated circuit card 
(ICC) procedures necessary to effect a payment system transaction in an 
international interchange environment. 


The Integrated Circuit Card Specifications for Payment Systems includes the 
following additional documents, all available on http://www.emvco.com: 


e Book 1 - Application Independent ICC to Terminal Interface Requirements 
e Book 2 - Security and Key Management 
e Book 4 - Cardholder, Attendant, and Acquirer Interface Requirements 


1.1 Changes in Version 4.3 


This release incorporates all relevant Specification Update Bulletins, Application 
Notes, amendments, etc. published up to the date of this release. 


The Revision Log at the beginning of the Book provides additional detail about 
changes to this specification. 


1.2 Structure 


Book 8 consists of the following parts: 


Part I - General 

PartII - Data Elements and Commands 

Part III - Debit and Credit Application Specification 
PartIV - Annexes 

Part V - Common Core Definitions 


Part I includes this introduction, as well as data applicable to all Books: 
normative references, definitions, abbreviations, notations, data element format 
convention, and terminology. 


Part II describes data elements and files as well as commands for financial 
transaction. 
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Part III specifies the debit and credit application functions including: 


e Transaction flow (the sequence of events and the commands issued to the 
card) 


e Exception processing 


e Definition of data elements and commands as they apply to the exchange of 
information between an ICC and a terminal. In particular, 


« Structure and referencing of files 


« The usage of commands between the ICC and the terminal to achieve 
application level functions. 


The functions described are those necessary to ensure that payment system cards 
conforming to this specification can perform a set of core functions in terminals 
conforming to this specification. Application functions unique to individual 
payment systems and those functions not performed in interchange are not 
described, but are not precluded. 


Part IV includes a complete data elements dictionary, rules for BER-TLV data 
objects, instructions for coding of specific data elements, and transaction log 
information. It discusses TVR and TSI bit settings following script processing, 
and Status Words returned in response to an EXTERNAL AUTHENTICATE 
command. 


Part V defines an optional extension to be used when implementing a card 
complying to the Common Core Definitions (CCD). 


The Book also includes a revision log and an index. 


This specification does not address clearing and settlement or any transactions 
where the ICC is not present. 


1.3 Underlying Standards 


This specification is based on the ISO/IEC 7816 series of standards and should be 
read in conjunction with those standards. However, if any of the provisions or 
definitions in this specification differ from those standards, the provisions herein 
shall take precedence. 


1.4 Audience 


This specification is intended for use by manufacturers of ICCs and terminals, 
system designers in payment systems, and financial institution staff responsible 
for implementing financial applications in ICCs. 
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2 Normative References 


The following standards contain provisions that are referenced in these 
specifications. The latest version shall apply unless a publication date is 
explicitly stated. 


ISO 639-1 Codes for the representation of names of 
languages — Part 1: Alpha-2 Code 


Note: This standard is updated continuously by ISO. 
Additions/changes to ISO 639-1:1988: Codes for the 
Representation of Names of Languages are available 
on: 

http://www.loc.gov/standards/iso639- 
2/php/code_changes.php 


ISO 3166 Codes for the representation of names of countries 
and their subdivisions 


ISO 4217 Codes for the representation of currencies and 
funds 

ISO/IEC 7811-1 Identification cards — Recording technique — 
Part 1: Embossing 

ISO/IEC 7811-83 Identification cards — Recording technique — 
Part 3: Location of embossed characters on ID-1 
cards 

ISO/IEC 7813 Identification cards — Financial transaction cards 

ISO/IEC 7816-1 Identification cards — Integrated circuit(s) cards 


with contacts — Part 1: Physical characteristics 


ISO/IEC 7816-2 Information technology — Identification cards — 
Integrated circuit(s) cards with contacts — Part 2: 
Dimensions and location of contacts 


ISO/IEC 7816-3 Identification cards — Integrated circuit cards — 
Part 3: Cards with contacts — Electrical interface 
and transmission protocols 
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ISO/IEC 7816-4 


ISO/IEC 7816-5 


ISO/IEC 7816-6 


ISO 8583:1987 


ISO 8583:1993 


ISO/IEC 8825-1 


ISO/IEC 8859 


ISO 9362 


ISO 9564-1:2011 


ISO/IEC 9796-2:2010 


ISO/IEC 9797-1:2011 


ISO/IEC 10116 


ISO/IEC 10118-3 


Identification cards — Integrated circuit cards — 
Part 4: Organization, security and commands for 
interchange 


Identification cards — Integrated circuit cards — 
Part 5: Registration of application providers 


Identification cards — Integrated circuit cards — 
Part 6: Interindustry data elements for 
interchange 


Bank card originated messages — Interchange 
message specifications — Content for financial 
transactions 


Financial transaction card originated messages — 
Interchange message specifications 


Information technology — ASN.1 encoding rules: 
Specification of Basic Encoding Rules (BER), 
Canonical Encoding Rules (CER) and 
Distinguished Encoding Rules (DER) 


Information processing — 8-bit single-byte coded 
graphic character sets 


Banking — Banking telecommunication messages — 
Bank identifier codes 


Financial services — Personal Identification 
Number (PIN) management and security — Part 1: 
Basic principles and requirements for PINs in 
card-based systems 


Information technology — Security techniques — 
Digital signature schemes giving message recovery 
— Part 2: Integer factorization based mechanisms 


Information technology — Security techniques — 
Message Authentication Codes - Part 1: 
Mechanisms using a block cipher 


Information technology — Security techniques — 
Modes of operation for an n-bit block cipher 


Information technology — Security techniques — 
Hash-functions — Part 3: Dedicated hash-functions 
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ISO/IEC 10373 Identification cards — Test methods 

ISO 13491-1 Banking — Secure cryptographic devices (retail) — 
Part 1: Concepts, requirements and evaluation 
methods 

ISO 13616 Banking and related financial services — 


International bank account number (IBAN) 


ISO 16609 Banking — Requirements for message 
authentication using symmetric techniques 


ISO/IEC 18031 Information technology - Security techniques - 
Random bit generation 


ISO/IEC 18033-3 Information technology — Security techniques — 
Encryption algorithms — Part 3: Block ciphers 
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3 Definitions 


The following terms are used in one or more books of these specifications. 


Accelerated 
Revocation 


Application 
Application 
Authentication 


Cryptogram 


Application 
Cryptogram 


Authorisation 
Request Cryptogram 


Authorisation 
Response 
Cryptogram 
Asymmetric 


Cryptographic 
Technique 


Authentication 


Block 


Byte 


A key revocation performed on a date sooner than the 
published key expiry date. 


The application protocol between the card and the 
terminal and its related set of data. 


An Application Cryptogram generated by the card 
when declining a transaction 


A cryptogram generated by the card in response to a 
GENERATE AC command. See also: 


e Application Authentication Cryptogram 
e Authorisation Request Cryptogram 
e Transaction Certificate 


An Application Cryptogram generated by the card 
when requesting online authorisation 


A cryptogram generated by the issuer in response to 
an Authorisation Request Cryptogram. 


A cryptographic technique that uses two related 
transformations, a public transformation (defined by 
the public key) and a private transformation (defined 
by the private key). The two transformations have the 
property that, given the public transformation, it is 
computationally infeasible to derive the private 
transformation. 


The provision of assurance of the claimed identity of 
an entity or of data origin. 


A succession of characters comprising two or three 
fields defined as prologue field, information field, and 
epilogue field. 


8 bits. 
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Card A payment card as defined by a payment system. 


Certificate The public key and identity of an entity together with 
some other information, rendered unforgeable by 
signing with the private key of the certification 
authority which issued that certificate. 


Certification Trusted third party that establishes a proof that links 

Authority a public key and other relevant information to its 
owner. 

Ciphertext Enciphered information. 

Cold Reset The reset of the ICC that occurs when the supply 


voltage (VCC) and other signals to the ICC are raised 
from the inactive state and the reset (RST) signal is 
applied. 


Combined A form of offline dynamic data authentication. 
DDA/Application 

Cryptogram 

Generation 


Command A message sent by the terminal to the ICC that 
initiates an action and solicits a response from the 


ICC. 
Compromise The breaching of secrecy or security. 


Concatenation Two elements are concatenated by appending the 
bytes from the second element to the end of the first. 
Bytes from each element are represented in the 
resulting string in the same sequence in which they 
were presented to the terminal by the ICC, that is, 
most significant byte first. Within each byte bits are 
ordered from most significant bit to least significant. 
A list of elements or objects may be concatenated by 
concatenating the first pair to form a new element, 
using that as the first element to concatenate with the 
next in the list, and so on. 


Contact A conducting element ensuring galvanic continuity 
between integrated circuit(s) and external interfacing 


equipment. 


Cryptogram Result of a cryptographic operation. 
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3 Definitions 


Cryptographic 
Algorithm 


Data Integrity 
Deactivation 
Sequence 
Decipherment 


Digital Signature 


Dynamic Data 
Authentication 
Embossing 
Encipherment 


Epilogue Field 


Exclusive-OR 


Financial 
Transaction 


Function 


An algorithm that transforms data in order to hide or 
reveal its information content. 


The property that data has not been altered or 
destroyed in an unauthorised manner. 


The deactivation sequence defined in section 6.1.5 of 
Book 1. 


The reversal of a corresponding encipherment. 


An asymmetric cryptographic transformation of data 
that allows the recipient of the data to prove the 
origin and integrity of the data, and protect the 
sender and the recipient of the data against forgery by 
third parties, and the sender against forgery by the 
recipient. 


A form of offline dynamic data authentication 
Characters raised in relief from the front surface of a 
card. 


The reversible transformation of data by a 
cryptographic algorithm to produce ciphertext. 


The final field of a block. It contains the error 
detection code (EDC) byte(s). 


Binary addition with no carry, giving the following 
values: 


0+0=0 
0O+1=1 
1+0=1 
1+1=0 


The act between a cardholder and a merchant or 
acquirer that results in the exchange of goods or 
services against payment. 


A process accomplished by one or more commands and 
resultant actions that are used to perform all or part 
of a transaction. 
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Guardtime The minimum time between the trailing edge of the 
parity bit of a character and the leading edge of the 
start bit of the following character sent in the same 
direction. 


Hash Function A function that maps strings of bits to fixed-length 
strings of bits, satisfying the following two properties: 


e It is computationally infeasible to find for a given 
output an input which maps to this output. 


e Itis computationally infeasible to find for a given 
input a second input that maps to the same 
output. 


Additionally, if the hash function is required to be 
collision-resistant, it must also satisfy the following 
property: 


e It is computationally infeasible to find any two 
distinct inputs that map to the same output. 


Hash Result The string of bits that is the output of a hash function. 


Inactive The supply voltage (VCC) and other signals to the ICC 
are in the inactive state when they are at a potential 
of 0.4 V or less with respect to ground (GND). 


Integrated Circuit The sub-assembly embedded into the ICC comprising 
Module the IC, the IC carrier, bonding wires, and contacts. 


Integrated Circuit(s) Electronic component(s) designed to perform 
processing and/or memory functions. 


Integrated Circuit(s) A card into which one or more integrated circuits are 
Card inserted to perform processing and memory functions. 


Interface Device That part of a terminal into which the ICC is inserted, 
including such mechanical and electrical devices as 
may be considered part of it. 


Issuer Action Code Any of the following, which reflect the issuer-selected 
action to be taken upon analysis of the TVR: 


e Issuer Action Code - Default 
e Issuer Action Code - Denial 
e Issuer Action Code - Online 
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3 Definitions 


Kernel 


Key 


Key Expiry Date 


Key Introduction 


Key Life Cycle 


Key Replacement 


Key Revocation 


Key Revocation Date 


Key Withdrawal 


Keypad 


The set of functions required to be present on every 
terminal implementing a specific interpreter. The 
kernel contains device drivers, interface routines, 
security and control functions, and the software for 
translating from the virtual machine language to the 
language used by the real machine. In other words, 
the kernel is the implementation of the virtual 
machine on a specific real machine. 


A sequence of symbols that controls the operation of a 
cryptographic transformation. 


The date after which a signature made with a 
particular key is no longer valid. Issuer certificates 
signed by the key must expire on or before this date. 
Keys may be removed from terminals after this date 
has passed. 


The process of generating, distributing, and beginning 
use of a key pair. 


All phases of key management, from planning and 
generation, through revocation, destruction, and 
archiving. 


The simultaneous revocation of a key and introduction 
of a key to replaced the revoked one. 


The key management process of withdrawing a key 
from service and dealing with the legacy of its use. 
Key revocation can be as scheduled or accelerated. 


The date after which no legitimate cards still in use 
should contain certificates signed by this key, and 
therefore the date after which this key can be deleted 
from terminals. For a planned revocation the Key 
Revocation Date is the same as the key expiry date. 


The process of removing a key from service as part of 
its revocation. 


Arrangement of numeric, command, and, where 
required, function and/or alphanumeric keys laid out 
in a specific manner. 
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Library 


Logical Compromise 


Magnetic Stripe 


Message 


Message 
Authentication Code 


Nibble 


Padding 
Path 


Payment System 
Environment 


Physical 
Compromise 


PIN Pad 


Plaintext 


Planned Revocation 


A set of high-level software functions with a published 
interface, providing general support for terminal 
programs and/or applications. 


The compromise of a key through application of 
improved cryptanalytic techniques, increases in 
computing power, or combination of the two. 


The stripe containing magnetically encoded 
information. 


A string of bytes sent by the terminal to the card or 
vice versa, excluding transmission-control characters. 


A symmetric cryptographic transformation of data 
that protects the sender and the recipient of the data 
against forgery by third parties. 


The four most significant or least significant bits of a 
byte. 


Appending extra bits to either side of a data string. 
Concatenation of file identifiers without delimitation. 


A logical construct within the ICC, the entry point to 
which is a Directory Definition File (DDF) named 
'1IPAY.SYS.DDFO01'. This DDF contains a Payment 
System Directory which in turn contains entries for 
one or more Application Definition Files (ADFs) which 
are formatted according to this specification. 


The compromise of a key resulting from the fact that 
it has not been securely guarded, or a hardware 
security module has been stolen or accessed by 
unauthorised persons. 


Arrangement of numeric and command keys to be 
used for personal identification number (PIN) entry. 


Unenciphered information. 


A key revocation performed as scheduled by the 
published key expiry date. 
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Potential 
Compromise 


Private Key 


Prologue Field 


Public Key 


Public Key 
Certificate 


Response 


Script 


Secret Key 
Signal Amplitude 
Signal 


Perturbations 


Socket 


A condition where cryptanalytic techniques and/or 
computing power has advanced to the point that 
compromise of a key of a certain length is feasible or 
even likely. 


That key of an entity’s asymmetric key pair that 
should only be used by that entity. In the case of a 
digital signature scheme, the private key defines the 
signature function. 


The first field of a block. It contains subfields for node 
address (NAD), protocol control byte (PCB), and 
length (LEN). 


That key of an entity’s asymmetric key pair that can 
be made public. In the case of a digital signature 
scheme, the public key defines the verification 
function. 


The public key information of an entity signed by the 
certification authority and thereby rendered 
unforgeable. 


A message returned by the ICC to the terminal after 
the processing of a command message received by the 
ICC. 


A command or a string of commands transmitted by 
the issuer to the terminal for the purpose of being sent 
serially to the ICC as commands. 


A key used with symmetric cryptographic techniques 
and usable only by a set of specified entities. 


The difference between the high and low voltages of a 
signal. 


Abnormalities occurring on a signal during normal 
operation such as undershoot/overshoot, electrical 
noise, ripple, spikes, crosstalk, etc. Random 
perturbations introduced from external sources are 
beyond the scope of this specification. 


An execution vector defined at a particular point in an 
application and assigned a unique number for 
reference. 
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State H 


State L 


Static Data 
Authentication 


Symmetric 
Cryptographic 
Technique 


T=0 


T=1 


Template 


Terminal 


Terminal Action 
Code 


Terminate Card 
Session 


Terminate 
Transaction 


Voltage high on a signal line. May indicate a logic one 
or logic zero depending on the logic convention used 
with the ICC. 


Voltage low on a signal line. May indicate a logic one 
or logic zero depending on the logic convention used 
with the ICC. 


Offline static data authentication 


A cryptographic technique that uses the same secret 
key for both the originator’s and recipient’s 
transformation. Without knowledge of the secret key, 
it is computationally infeasible to compute either the 
originator’s or the recipient’s transformation. 


Character-oriented asynchronous half duplex 
transmission protocol. 


Block-oriented asynchronous half duplex transmission 
protocol. 


Value field of a constructed data object, defined to give 
a logical grouping of data objects. 


The device used in conjunction with the ICC at the 
point of transaction to perform a financial transaction. 
The terminal incorporates the interface device and 
may also include other components and interfaces 
such as host communications. 


Any of the following, which reflect the 
acquirer-selected action to be taken upon analysis of 
the TVR: 


e Terminal Action Code - Default 
e Terminal Action Code - Denial 
e Terminal Action Code - Online 


End the card session by deactivating the IFD contacts 
according to section 6.1.5 of Book 1, and displaying a 
message indicating that the ICC cannot be used to 
complete the transaction 


Stop the current application and deactivate the card. 
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3 Definitions 


Transaction 


Transaction 
Certificate 


Virtual Machine 


Warm Reset 


An action taken by a terminal at the user’s request. 
For a POS terminal, a transaction might be payment 
for goods, etc. A transaction selects among one or 
more applications as part of its processing flow. 


An Application Cryptogram generated by the card 
when accepting a transaction 


A theoretical microprocessor architecture that forms 
the basis for writing application programs in a specific 
interpreter software implementation. 


The reset that occurs when the reset (RST) signal is 
applied to the ICC while the clock (CLK) and supply 
voltage (VCC) lines are maintained in their active 
state. 
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4 Abbreviations, Notations, Conventions, and 


Terminology 
4.1 Abbreviations 
pA Microampere 
um Micrometre 
us Microsecond 
a Alphabetic (see section 4.3, Data Element Format Convention) 
AAC Application Authentication Cryptogram 
AC Application Cryptogram 
ACK Acknowledgment 
ADF Application Definition File 
AEF Application Elementary File 
AFL Application File Locator 
AID Application Identifier 
AIP Application Interchange Profile 
an Alphanumeric (see section 4.3) 
ans Alphanumeric Special (see section 4.3) 
APDU Application Protocol Data Unit 
API Application Program Interface 
ARC Authorisation Response Code 
ARPC Authorisation Response Cryptogram 
ARQC Authorisation Request Cryptogram 
ASI Application Selection Indicator 
ASN Abstract Syntax Notation 
ATC Application Transaction Counter 
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4.1 Abbreviations Application Specification 
ATM Automated Teller Machine 

ATR Answer to Reset 

AUC Application Usage Control 

b Binary (see section 4.3) 

BCD Binary Coded Decimal 

BER Basic Encoding Rules (defined in ISO/IEC 8825-1) 
BIC Bank Identifier Code 

BGT Block Guardtime 

BWI Block Waiting Time Integer 

BWT Block Waiting Time 

C Celsius or Centigrade 

CAD Card Accepting Device 

C-APDU Command APDU 

CBC Cipher Block Chaining 

CCD Common Core Definitions 

CCI Common Core Identifier 

CDA Combined DDA/Application Cryptogram Generation 
CDOL Card Risk Management Data Object List 

CID Cryptogram Information Data 

CIN Input Capacitance 

CLA Class Byte of the Command Message 

CLK Clock 

cn Compressed Numeric (see section 4.3) 

CPU Central Processing Unit 

CRL Certificate Revocation List 

CSU Card Status Update 

C-TPDU Command TPDU 

CV Cryptogram Version 
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4 Abbreviations, Notations, Conventions, and Terminology 
4.1 Abbreviations 


CVM 
CVR 
CV Rule 


Hex 
HHMMSS 
/O 


Cardholder Verification Method 
Card Verification Results 
Cardholder Verification Rule 
Character Waiting Time Integer 
Character Waiting Time 

Bit Rate Adjustment Factor 
Destination Node Address 
Direct Current 

Dynamic Data Authentication 
Directory Definition File 
Dynamic Data Authentication Data Object List 
Data Encryption Standard 
Dedicated File 

Directory 

Data Object List 

Electronic Code Book 

Error Detection Code 
Elementary File 

European Norm 

Elementary Time Unit 
Frequency 

Format Code 

File Control Information 
Ground 

Grandparent key for session key generation 
Hexadecimal 

Hours, Minutes, Seconds 


Input/Output 


November 2011 


Page 21 


4 Abbreviations, Notations, Conventions, and Terminology EMV 4.3 Book 3 


4.1 Abbreviations Application Specification 

IAC Issuer Action Code (Denial, Default, Online) 

IAD Issuer Application Data 

IBAN International Bank Account Number 

I-block Information Block 

IC Integrated Circuit 

ICC Integrated Circuit(s) Card 

Icc Current drawn from VCC 

IEC International Electrotechnical Commission 

IFD Interface Device 

IFS Information Field Size 

IFSC Information Field Size for the ICC 

IFSD Information Field Size for the Terminal 

IFSI Information Field Size Integer 

IIN Issuer Identification Number 

IK Intermediate Key for session key generation 

INF Information Field 

INS Instruction Byte of Command Message 

Ion High Level Output Current 

lou Low Level Output Current 

ISO International Organization for Standardization 

IV Initial Vector for session key generation 

Ku Master Key 

Ks Session Key 

L Length 

Ls: Least Significant 

Le Exact Length of Data Sent by the TAL in a Case 8 or 4 
Command 

LCOL Lower Consecutive Offline Limit 
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4 Abbreviations, Notations, Conventions, and Terminology 
4.1 Abbreviations 


Lpp 


Le 


LEN 


Licc 


Length of the ICC Dynamic Data 


Maximum Length of Data Expected by the TAL in Response to 
a Case 2 or 4 Command 


Length 


Exact Length of Data Available or Remaining in the ICC (as 
Determined by the ICC) to be Returned in Response to the 
Case 2 or 4 Command Received by the ICC 


Length of Response Data Field 
Longitudinal Redundancy Check 
Mandatory 

Milliohm 

Megohm 

Most Significant 

Meters per Second 
Milliampere 

Message Authentication Code 
Maximum 

Master File 


Megahertz 


Minimum 

ICC Master Key for session key generation 
Millimetre 

Month, Day 

Month, Year 

Newton 

Numeric (see section 4.3) 

Node Address 


Negative Acknowledgment 


Nanoampere-second 
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Application Specification 


PAN 


Pca 
PCB 
PDOL 
pF 

Pr 

Pic 
PIN 
PIX 
POS 
pos. 
PSE 
PTS 
R-APDU 


Length of the Certification Authority Public Key Modulus 
Norme Frangaise 

Length of the Issuer Public Key Modulus 

Length of the ICC Public Key Modulus 

National Institute for Standards and Technology 
Length of the ICC PIN Encipherment Public Key Modulus 
Nanosecond 

Optional 

Operating System 

Parent key for session key generation 
Parameter 1 

Parameter 2 

Parameter 3 

Primary Account Number 

Personal Computer 

Certification Authority Public Key 

Protocol Control Byte 

Processing Options Data Object List 

Picofarad 

Issuer Public Key 

ICC Public Key 

Personal Identification Number 

Proprietary Application Identifier Extension 
Point of Service 

Position 

Payment System Environment 

Protocol Type Selection 

Response APDU 
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4 Abbreviations, Notations, Conventions, and Terminology 
4.1 Abbreviations 


R-block 
RFU 
RID 
RSA 
RST 
SAD 
S-block 
Sca 
SDA 
SFI 
SHA-1 
SI 

Sic 

SK 
SW1 
SW2 
TAC 
TAL 
TC 
TCK 
TDOL 
tr 
TLV 
TPDU 
tR 

TS 
TSI 
TTL 


Receive Ready Block 

Reserved for Future Use 

Registered Application Provider Identifier 

Rivest, Shamir, Adleman Algorithm 

Reset 

Source Node Address 

Supervisory Block 

Certification Authority Private Key 

Static Data Authentication 

Short File Identifier 

Secure Hash Algorithm 1 

Issuer Private Key 

ICC Private Key 

Session Key for session key generation 

Status Byte One 

Status Byte Two 

Terminal Action Code(s) (Default, Denial, Online) 
Terminal Application Layer 

Transaction Certificate 

Check Character 

Transaction Certificate Data Object List 

Fall Time Between 90% and 10% of Signal Amplitude 
Tag Length Value 

Transport Protocol Data Unit 

Rise Time Between 10% and 90% of Signal Amplitude 
Initial Character 

Transaction Status Information 


Terminal Transport Layer 
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4.1 Abbreviations 


Application Specification 


YYMMDD 


Terminal Verification Results 
Upper Consecutive Offline Limit 
Underwriters Laboratories Incorporated 
Volt 

Variable (see section 4.3) 

Voltage Measured on VCC Contact 
Supply Voltage 

High Level Input Voltage 

Low Level Input Voltage 

High Level Output Voltage 

Low Level Output Voltage 
Programming Voltage 

Voltage Measured on VPP contact 
Waiting Time Integer 

Waiting Time Extension 

Work Waiting Time 

Year, Month 

Year, Month, Day 
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4 Abbreviations, Notations, Conventions, and Terminology 
4.2 Notations 


4.2 Notations 


'0' to '9' and 'A' to 'F" 


XX 
A:=B 

A=B 
A=Bmodn 
Amodn 

A/n 

Y := ALG(K)[X] 
X = ALG-1(K)[Y] 


Y := Sign (Sx)[X] 


X = Recover(Px)[Y] 


C:=(A || B) 


Leftmost 


16 hexadecimal characters 

Any value 

A is assigned the value of B 

Value of A is equal to the value of B 


Integers A and B are congruent modulo the integer n, 
that is, there exists an integer d such that 


(A—B)=dn 


The reduction of the integer A modulo the integer n, that 
is, the unique integer r, 0 <r <n, for which there exists 
an integer d such that 


A=dntr 


The integer division of A by n, that is, the unique 
integer d for which there exists an integer r, 0<r<n, 
such that 


A=dnt+r 


Encipherment of a data block X with a block cipher as 
specified in Annex A1 of Book 2, using a secret key K 


Decipherment of a data block Y with a block cipher as 
specified in Annex A1 of Book 2, using a secret key K 


The signing of a data block X with an asymmetric 
reversible algorithm as specified in Annex A2 of Book 2, 
using the private key Sx 


The recovery of the data block X with an asymmetric 
reversible algorithm as specified in Annex A2 of Book 2, 
using the public key Px 


The concatenation of an n-bit number A and an m-bit 
number B, which is defined as C= 2™ A+ B. 


Applies to a sequence of bits, bytes, or digits and used 
interchangeably with the term “most significant”. If 
C =(A || B) as above, then A is the leftmost n bits of C. 
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Rightmost Applies to a sequence of bits, bytes, or digits and used 
interchangeably with the term “least significant”. If 
C =(A || B) as above, then B is the rightmost m bits 
of C. 


H := Hash[MSG] Hashing of a message MSG of arbitrary length using a 
160-bit hash function 


X@Y The symbol '' denotes bit-wise exclusive-OR and is 
defined as follows: 


X@®Y ~ The bit-wise exclusive-OR of the data blocks 
X and Y. If one data block is shorter than the 
other, then it is first padded to the left with 
sufficient binary zeros to make it the same 
length as the other. 
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4.3 


Data Element Format Conventions 


The EMV specifications use the following data element formats: 


a 


an 


ans 


cn 


Alphabetic data elements contain a single character per byte. The 
permitted characters are alphabetic only (a to z and A to Z, upper and 
lower case). 


Alphanumeric data elements contain a single character per byte. The 
permitted characters are alphabetic (a to z and A to Z, upper and lower 
case) and numeric (0 to 9). 


Alphanumeric Special data elements contain a single character per byte. 
The permitted characters and their coding are shown in the Common 
Character Set table in Annex B of Book 4. 


There is one exception: The permitted characters for Application 
Preferred Name are the non-control characters defined in the 

ISO/IEC 8859 part designated in the Issuer Code Table Index associated 
with the Application Preferred Name. 


These data elements consist of either unsigned binary numbers or bit 
combinations that are defined elsewhere in the specification. 


Binary example: The Application Transaction Counter (ATC) is defined 
as “b” with a length of two bytes. An ATC value of 19 is stored as Hex 
'00 13'. 


Bit combination example: Processing Options Data Object List (PDOL) 
is defined as “b” with the format shown in section 5.4. 


Compressed numeric data elements consist of two numeric digits 
(having values in the range Hex '0'—9') per byte. These data elements 
are left justified and padded with trailing hexadecimal 'F's. 


Example: The Application Primary Account Number (PAN) is defined as 
“cn” with a length of up to ten bytes. A value of 1234567890123 may be 
stored in the Application PAN as Hex '12 34 56 78 90 12 3F FF" witha 
length of 8. 


Numeric data elements consist of two numeric digits (having values in 
the range Hex '0' —'9') per byte. These digits are right justified and 
padded with leading hexadecimal zeroes. Other specifications 

sometimes refer to this data format as Binary Coded Decimal (“BCD”) or 
unsigned packed. 


Example: Amount, Authorised (Numeric) is defined as “n 12” with a 
length of six bytes. A value of 12345 is stored in Amount, Authorised 
(Numeric) as Hex '00 00 00 01 23 45". 
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var. Variable data elements are variable length and may contain any bit 
combination. Additional information on the formats of specific variable 
data elements is available elsewhere. 
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4.4 Terminology 


proprietary Not defined in this specification and/or outside the scope 
of this specification 


shall Denotes a mandatory requirement 


should Denotes a recommendation 
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Data Elements and 
Commands 
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5 Data Elements and Files 


An application in the Integrated Circuit Card (ICC) includes a set of items of 
information. These items of information may be accessible to the terminal after a 
successful application selection (see section 12 of Book 1). 


An item of information is called a data element. A data element is the smallest 
piece of information that may be identified by a name, a description of logical 
content, a format, and a coding. 


5.1 Data Elements Associated with Financial 
Transaction Interchange 


The data elements dictionary defined in Annex A includes those data elements 
that may be used for financial transaction interchange. Data elements not 
specified in Annex A are outside the scope of these specifications. 


Any additional data element transmitted in the response to the SELECT 
command (for example, O/S Manufacturer proprietary data) is placed in the field 
“FCI Issuer Discretionary Data” (tag 'BFOC’). 
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5.2 Data Objects 


A data object consists of a tag, a length, and a value. A tag uniquely identifies a 
data object within the environment of an application. The length is the length of 
the value field of the data object. The value field of a data object may consist of 
either a single data element or one or more data objects. When a data object 
encapsulates a single data element, it is called a primitive data object. When a 
data object encapsulates one or more data objects, it is called a constructed data 
object. Specific tags are assigned to the constructed data objects with a specific 
meaning in the environment of an application according to this specification. The 
value field of such constructed data objects is a context-specific template. Rules 
for the coding of context-specific data objects and templates are given in Annex B. 


Upon receipt, the terminal shall parse all the data elements following the rules 
described in Annex B. The retrieved value fields of the data elements shall be 
stored in the terminal buffer for possible later use in the application. 


The terminal shall be capable of correctly interpreting Tag Length Value (TLV) 
data objects with a length field coded '00' as defined in ISO/IEC 7816. This 
situation can occur when a data element is personalised on a card without an 
actual value field. A data element with length '00' shall be treated as not present. 
The data element length indicated in Annex A reflects the length of the data 
elements when actually present on the card. 


Annex A describes the mapping of data elements onto data objects and the 
mapping of data objects into templates when applicable. 


Records are templates containing one or more primitive and/or constructed data 
objects. 


The mapping of data objects into records is left to the discretion of the issuer. The 
manner in which data elements are to be used is described in Part III. 


Annex B defines the tags that are reserved by this specification for EMVCo, the 
payment systems, and issuers. All ICC applications conforming to this 
specification shall comply with this coding and allocation scheme in accordance 
with ISO/IEC 7816-6. 


5.2.1 Classes of Data Objects 


Identification and coding of different classes of data objects are defined in Annex 
B. The tag definitions specified in that annex are according to ISO/IEC 8825 and 
the ISO/IEC 7816 series and apply to applications conforming to this 
specification. 
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5.3 Files 


The data objects contained in data files accessible from the ICC are stored in 
records. The file structure and referencing method depend on the purpose of the 
file. The following sections describe structures and referencing methods. The 
layout of the data files accessible from the ICC is left to the discretion of the 
issuer except for the directory files described in the following section. 


5.3.1 Application Elementary Files 


An Application Elementary File (AEF) in the range 1-10, contains one or more 
primitive Basic Encoding Rules - TLV (BER-TLV) data objects grouped into 
constructed BER-TLV data objects (records) according to Annex B. After selecting 
the application, an AEF in the range 1-10 is referred to only by its SFI as 
described in section 5.3.2.2. 


A data file referred to in this specification consists of a sequence of records 
addressed by record number. The data files referred to by SFIs in the range 1-10 
contain only data not interpreted by the card, that is, data that is not used by the 
card in its internal processes. This file structure is defined as linear. It can be 
either linear fixed or linear variable according to ISO/IEC 7816-4. The choice is 
left to the issuer and does not affect the reading of the file according to this 
specification. 


5.3.2 File Referencing 


A file may be referred to by a name or a SFI depending on its type. 


5.3.2.1 Referencing by Name 


Any Application Definition File (ADF) or Directory Definition File (DDF) in the 
card is referenced by its Dedicated File (DF) name. A DF name for an ADF 
corresponds to the Application Identifier (AID) or contains the AID as the 
beginning of the DF name. Each DF name shall be unique within a given card. 
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5.3.2.2 Referencing by SFI 


SFIs are used for the selection of AEFs. Any AEF within a given application is 
referenced by a SFI coded on 5 bits in the range 1 to 30. The coding of the SFI is 
described in every command that uses it. 


Table 1 describes the assignment of SFIs for an EMV application: 


Cvaiwe [Weaning 
Governed by this specification 


11-20 | Payment system-specific 


Table 1: Structure of SFI 


A SFI shall be unique within an application. The coding of SFIs within the range 
1 to 10 is used to address AEFs governed by this specification. 


5.4 Rules for Using a Data Object List (DOL) 


In several instances, the terminal is asked to build a flexible list of data elements 
to be passed to the card under the card’s direction. To minimise processing within 
the ICC, such a list is not TLV encoded but is a single constructed field built by 
concatenating several data elements together. Since the elements of the 
constructed field are not TLV encoded, it is imperative that the ICC knows the 
format of this field when the data is received. This is achieved by including a 
Data Object List (DOL) in the ICC, specifying the format of the data to be 
included in the constructed field. DOLs currently used in this specification 
include: 


e the Processing Options Data Object List (PDOL) used with the GET 
PROCESSING OPTIONS command 


e the Card Risk Management Data Object Lists (CDOL1 and CDOL2) used 
with the GENERATE APPLICATION CRYPTOGRAM (AC) command 


e the Transaction Certificate Data Object List (TDOL) used to generate a TC 
Hash Value 


e the Dynamic Data Authentication Data Object List (DDOL) used with the 
INTERNAL AUTHENTICATE command 


This section describes the rules for constructing a field using a DOL supplied by 
the card. 
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A DOL is a concatenated list of entries, with each entry representing a single 
data element to be included in the constructed field. The format of each entry is a 
one- or two-byte tag identifying the desired data object, followed by a one-byte 
length which represents the number of bytes the field shall occupy in the 
command data. Only tags representing primitive data objects constructed 
according to Annex B shall be used in DOLs. 


The terminal shall complete the following steps to build the constructed field: 
1. Read the DOL from the ICC. 


2. Concatenate all data elements listed in the DOL. The following rules apply to 
this concatenation: 


a. Ifthe tag of any data object identified in the DOL is unknown to the 
terminal or represents a constructed data object, the terminal shall 
provide a data element with the length specified and a value of all 
hexadecimal zeroes. 


b. Ifa data object is in the list and is meaningful to the terminal but 
represents optional static data that is absent from the terminal, the 
portion of the command field representing the data object shall be filled 
with hexadecimal zeroes. 


c. Ifthe length specified in the DOL entry is less than the length of the 
actual data object, the leftmost bytes of the data element shall be 
truncated if the data object has numeric (n !) format, or the rightmost 
bytes of the data shall be truncated for any other format. 


d. Ifthe length specified in the DOL entry is greater than the length of the 
actual data, the actual data shall be padded: 


*" with leading hexadecimal zeroes if the data has numeric format 


« with trailing hexadecimal 'FF's if the data has compressed numeric 
(cn ') format 


« with trailing hexadecimal zeroes for any other format (an, ans or b 
including bit combination data !) 


e. Ifa data object is in the list and is meaningful to the terminal but 
represents data that is not applicable to the current transaction, the 
portion of the command field representing the data object shall be filled 
with hexadecimal zeroes. 


The completed list of data elements shall be concatenated in the sequence in 
which the corresponding data objects appear in the DOL. 


1 See section 4.3 Data Element Format Convention. 
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6 Commands for Financial Transaction 


6.1 Command APDU Format 


The command Application Protocol Data Unit (APDU) consists of a mandatory 
header of four bytes followed by a conditional body of variable length, as shown in 
Figure 1: 


< Mandatory Header? > |< Conditional Body > 


Figure 1: Command APDU Structure 


The number of data bytes sent in the command APDU (C-APDU) is denoted by 
Le (length of command data field). 


The maximum number of data bytes expected in the response APDU is denoted 
by length of expected data (Le). When Le is present and contains the value zero, 
the maximum number of available data bytes (up to 256) is expected. When 
required in a command message, Le shall always be set to '00'. 


6.2 Response APDU Format 


The response APDU format consists of a conditional body of variable length 
followed by a mandatory trailer of two bytes, as shown in Figure 2: 


swi_[ 8Wa 


< Body > < Trailer > 


Figure 2: Response APDU Structure 


The data field of a response APDU is an object structured as defined in Annex B. 
The detailed coding of the objects is provided with the commands described in 
subsequent sub-clauses. 


2 CLA = Class Byte of the Command Message 
INS = Instruction Byte of Command Message 
P1 = Parameter 1 


P2 = Parameter 2 
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6.3. Coding Conventions 


This section defines the coding of the header and the body of the messages 
(command and response). 


6.3.1 Coding of the Class Byte 


The most significant nibble of the class byte indicates the type of command as 
shown in Table 2: 


a Inter-industry command 


a Proprietary to this specification 
Any other value | Outside the scope of this specification 


Table 2: Most Significant Nibble of the Class Byte 


A command proprietary to this specification is introduced by the most significant 
nibble of the class byte set to 8; in other words, the structure of the command and 
response messages is according to ISO/IEC 7816-4, and the coding of the 
messages is defined within the context of these specifications. 


The least significant nibble of the class byte indicates secure messaging and 
logical channel mechanisms, according to ISO/IEC 7816-4. 


Page 42 November 2011 


EMV 4.3 Book 3 6 Commands for Financial Transaction 
Application Specification 6.3 Coding Conventions 


6.3.2 Coding of the Instruction Byte 


The INS byte of a command is structured according to Book 1 section 9.4.1. 
Table 3 indicates the coding of INS and its relationship to CLA: 


APPLICATION BLOCK 


CHANGE/UNBLOCK 


Table 3: Coding of the Instruction Byte 


Note: Additional INS codes may be assigned in the future by EMVCo using class '8x'. It 
is strongly recommended that application providers not define proprietary commands in 
class '8x' when they are to be used in the context of these specifications, so that collision 
is avoided. 


6.3.3 Coding of Parameter Bytes 


The parameter bytes P1 P2 may have any value. If not used, a parameter byte 
has the value '00'. 
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6.3.4 Coding of Data Field Bytes 


When present, a command APDU message data field consists of a string of data 
elements. 


When present, a response APDU message data field consists of a data object or a 
string of data objects encapsulated in a template according to Annex B. 


6.3.5 Coding of the Status Bytes 


The status bytes SW1 SW2 are returned by the transport layer to the application 
layer in any response message and denote the processing state of the command. 
The coding of the status words is structured as illustrated in Figure 3: 


SW1 SW2 
Process Completed Process Aborted 
Normal Warning Execution Checking 
‘'9000' '62xx' '63xx' '64xx' "65 xx' '67xx' to 


‘6Fxx' 


Figure 3: Structural Scheme of Status Bytes 
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pswa}sw2] Meaning 


Normal processing 
Process completed (any other value for SW2 is RFU) 


Warning processing 
State of non-volatile memory unchanged; selected file invalidated 
State of non-volatile memory changed; authentication failed 


State of non-volatile memory changed; counter provided by 'x' 
(from 0-15) 


Checking errors 
Command not allowed; authentication method blocked 
Command not allowed; referenced data invalidated 
Command not allowed; conditions of use not satisfied 


Wrong parameter(s) P1 P2; function not supported 


Wrong parameter(s) P1 P2; file not found 


Wrong parameter(s) P1 P2; record not found 
Referenced data (data objects) not found 


Table 4: Coding of Status Bytes SW1 SW2 
The following values of SW1 SW2 are described in Part II of Book 1 as they apply 
to the Transport Protocol Data Unit (TPDU) and are not returned to the APDU: 
e '61xx': SW2 indicates the number of response bytes still available. 
e '6Cxx': Wrong length Le, SW2 indicates the exact length. 


SW1 ='6x' or '90' denotes a normal, warning, or error condition coded according 
to ISO/IEC 7816-4. 


Other values of SW1 returned by the ICC are not supported by Book 1, Part II. 
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Table 5 shows the coding of the SW1 SW2 status bytes which this specification 
requires to be returned in response to specific conditions. The card may generate 


status bytes not listed in this table for error and warning conditions not specified 
in Part III. 


GENERATE APPLICATION CRYPTOGRAM 


EXTERNAL AUTHENTICATE 
GET PROCESSING OPTIONS 
INTERNAL AUTHENTICATE 


PIN CHANGE/UNBLOCK 


ST roscoe 
i =| |< vere 


APPLICATION UNBLOCK 


PET LT I I] caro erocx 


APPLICATION BLOCK 


GET DATA 


oe 


Pt | ff cercnanence 


a 
> 


Bo ~ Raeeee 
Oe - eee 


es ea 
Sie s 
eee * 


Table 5: Allocation of Status Bytes 


The following convention is used in the table: 


X = Allowed response code, for which a dedicated action shall be taken or 
which has a special meaning for an EMV compliant application. The 
meaning of the action is explained in section 10. 
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If during transaction processing as described in Part III, the card returns a value 
for SW1 SW2 other than those specified in Table 5, and no other action is 
indicated elsewhere in these specifications, the transaction shall be terminated. 
For example, if the application reads records in a file that contains four records 
and, in response to the READ RECORD command for record 5, the card returns 
SW1 SW2 ='6400' instead of SW1 SW2 = '6A83', then the transaction would be 
terminated. 


If during the processing of the GET DATA command, defined in section 6.5.7, the 
card returns an error condition, the terminal shall proceed as indicated in 
section 10.6.3 (for terminal velocity checking) or in section 6.3.4.1 of Book 4 (for 
cardholder verification processing). 


If during the processing of an issuer script command, as defined in section 10.10, 
the card returns a warning condition (SW1 SW2 = '62XX' or '63xx'), the terminal 
shall continue with the next command from the Issuer Script (if any). 


For the EXTERNAL AUTHENTICATE command, SW1 SW2 = '6300' means 
‘Authentication Failed’. 


6.3.6 Coding of RFU Data 


The coding of data (bits and bytes) indicated as RFU and marked as 'x' in the 
tables of the specifications shall be set to zero unless otherwise stated. 


To allow for migration and support of new functionality, the ICC and the 
terminal shall not verify the data indicated as RFU. 


6.4 Logical Channels 


A logical channel establishes and maintains the link between an application in 
the terminal and an application in the card. 


A card may support more than one logical channel but only the basic logical 
channel is supported by this specification. This limits to one the number of 
concurrent applications according to this specification. 
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6.5 Commands 


This section describes the following APDU command-response pairs: 


APPLICATION BLOCK (post-issuance command) 
APPLICATION UNBLOCK (post-issuance command) 
CARD BLOCK (post-issuance command) 
EXTERNAL AUTHENTICATE 

GENERATE APPLICATION CRYPTOGRAM 

GET CHALLENGE 

GET DATA 

GET PROCESSING OPTIONS 

INTERNAL AUTHENTICATE 

PIN CHANGE/UNBLOCK (post-issuance command) 
READ RECORD 

VERIFY 


The post-issuance commands shall only be sent using script processing (see 
section 10.10) and secure messaging as specified in Book 2. 
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6.5.1 APPLICATION BLOCK Command-Response APDUs 


6.5.1.1 Definition and Scope 


The APPLICATION BLOCK command is a post-issuance command that 
invalidates the currently selected application. 


Following the successful completion of an APPLICATION BLOCK command: 


e An invalidated application shall return the status bytes SW1 SW2 = '6283' 
(‘Selected file invalidated’) in response to a SELECT command. 


e An invalidated application shall return only an Application Authentication 
Cryptogram (AAC) as AC in response to a GENERATE AC command. 


6.5.1.2 Command Message 
The APPLICATION BLOCK command message is coded as shown in Table 6: 


'8C' or '84'; coding according to the secure messaging 
specified in Book 2 


'00'; all other values are RFU 
Number of data bytes 


Message Authentication Code (MAC) data 
component; coding according to the secure messaging 
specified in Book 2 


Not present 


Table 6: APPLICATION BLOCK Command Message 


6.5.1.3. Data Field Sent in the Command Message 


The data field of the command message contains the MAC data component coded 
according to the secure messaging format specified in Book 2. 


6.5.1.4 Data Field Returned in the Response Message 


No data field is returned in the response message. 


6.5.1.5 Processing State Returned in the Response Message 


'9000' indicates a successful execution of the command, whether the application 
was already invalidated or not. 
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6.5.2 APPLICATION UNBLOCK Command-Response 
APDUs 


6.5.2.1 Definition and Scope 


The APPLICATION UNBLOCK command is a post-issuance command that 
rehabilitates the currently selected application. 


Following the successful completion of an APPLICATION UNBLOCK command, 
the restrictions imposed by the APPLICATION BLOCK command are removed. 


6.5.2.2 Command Message 
The APPLICATION UNBLOCK command message is coded as shown in Table 7. 


'8C' or '84'; coding according to the secure messaging 
specified in Book 2 


'00'; all other values are RFU 
Number of data bytes 


Data | MAC data component; coding according to the secure 
messaging specified in Book 2 


Not present 


Table 7: APPLICATION UNBLOCK Command Message 


6.5.2.3 Data Field Sent in the Command Message 


The data field of the command message contains the MAC data component coded 
according to the secure messaging format specified in Book 2. 


6.5.2.4 Data Field Returned in the Response Message 


No data field is returned in the response message. 


6.5.2.5 Processing State Returned in the Response Message 


'9000' indicates a successful execution of the command, whether the application 
was previously invalidated or not. 
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6.5.3 CARD BLOCK Command-Response APDUs 


6.5.3.1 Definition and Scope 


The CARD BLOCK command is a post-issuance command that permanently 
disables all applications in the ICC. 


The CARD BLOCK command shall disable all applications in the ICC, including 
applications that may be selected implicitly. 


Following the successful completion of a CARD BLOCK command, all subsequent 
SELECT commands shall return the status bytes SW1 SW2 ='6A81' (‘Function 
not supported’) and perform no other action. 

6.5.3.2 © Command Message 


The CARD BLOCK command message is coded as shown in Table 8. 


'8C' or '84'; coding according to the secure messaging 
specified in Book 2 


'00'; all other values are RFU 
Number of data bytes 


Data | MAC data component; coding according to the secure 
messaging specified in Book 2 
Not present 


Table 8: CARD BLOCK Command Message 


6.5.3.3 Data Field Sent in the Command Message 


The data field of the command message contains the MAC data component coded 
according to the secure messaging format specified in Book 2. 


6.5.3.4 Data Field Returned in the Response Message 


No data field is returned in the response message. 


6.5.3.5 Processing State Returned in the Response Message 


'9000' indicates a successful execution of the command, whether the card was 
already blocked or not. 
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6.5.4 EXTERNAL AUTHENTICATE Command-Response 
APDUs 


6.5.4.1 Definition and Scope 


The EXTERNAL AUTHENTICATE command asks the application in the ICC to 
verify a cryptogram. 


The ICC returns the processing state of the command. 


6.5.4.2 Command Message 


The EXTERNAL AUTHENTICATE command message is coded as shown in 
Table 9: 


Issuer Authentication Data 
| Le | Not present 


Table 9: EXTERNAL AUTHENTICATE Command Message 


The reference of the algorithm (P1) of the EXTERNAL AUTHENTICATE 
command is coded '00', which means that no information is given. The reference 
of the algorithm either is known before issuing the command or is provided in the 
data field. 

6.5.4.3. Data Field Sent in the Command Message 


The data field of the command message contains the value field of tag '91' coded 
as follows: 


e mandatory first 8 bytes containing the cryptogram 


e optional additional 1-8 bytes are proprietary 


6.5.4.4 Data Field Returned in the Response Message 


No data field is returned in the response message. 
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6.5.4.5 Processing State Returned in the Response Message 
'9000' indicates a successful execution of the command. 
'6300' indicates ‘Issuer authentication failed’. 


For further information, see Annex F. 
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6.5.5 GENERATE APPLICATION CRYPTOGRAM 
Command-Response APDUs 


6.5.5.1 Definition and Scope 


The GENERATE AC command sends transaction-related data to the ICC, which 
computes and returns a cryptogram. This cryptogram shall either be an 
Application Cryptogram (AC) as specified in this specification or a proprietary 
cryptogram. In both cases, the cryptogram shall be of a type specified in Table 10 
(for more details, see section 9). 


This command is also used when performing the Combined DDA/Application 
Cryptogram Generation (CDA) function as described in Book 2 section 6.6. 


[type ——*d Abbreviation [Meaning | 


Application Authentication AAC Transaction declined 
Cryptogram 


Authorisation Request Cryptogram ARQC Online authorisation 
requested 


Transaction Certificate | TC _—‘| Transaction approved —_| Transaction approved 


Table 10: GENERATE AC Cryptogram Types 


The cryptogram returned by the ICC may differ from that requested in the 
command message according to an internal process in the ICC (as described in 
section 9). 

6.5.5.2 Command Message 


The GENERATE AC command message is coded as shown in Table 11: 


Transaction-related data 


Table 11: GENERATE AC Command Message 
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The reference control parameter of the GENERATE AC command is coded as 
shown in Table 12: 


pbs | b7 | b6 | bs | b4 | bs | b2 | bt | Meaning 
0 


0 


oO 
a 
oD) 
Q 


0 
1 
1 


H 
=e) 
ey 
Gq 


x RFU 


0 CDA signature not requested 


1 CDA signature requested 
X X X xX | RFU 


Table 12: GENERATE AC Reference Control Parameter 


6.5.5.3. Data Field Sent in the Command Message 

The content of the data field of the command message is coded according to the 
rules for the data object list as defined in section 5.4. 

6.5.5.4 Data Field Returned in the Response Message 


The data field of the response message consists of a BER-TLV coded data object. 
The coding of the data object shall be according to one of the following two 
formats. 


e Format 1: The data object returned in the response message is a primitive 
data object with tag equal to '80'. The value field consists of the concatenation 
without delimiters (tag and length) of the value fields of the data objects 
specified in Table 13: 


Cryptogram Information Data (CID) 
Application Transaction Counter (ATC) 


Application Cryptogram (AC) 
Issuer Application Data (IAD) | oo | 


Table 13: Format 1 GENERATE AC Response Message Data Field 
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e Format 2: The data object returned in the response message is a constructed 
data object with tag equal to'77'. The value field may contain several BER- 
TLV coded objects, but shall always include the Cryptogram Information 
Data, the Application Transaction Counter, and the cryptogram computed by 
the ICC (either an AC or a proprietary cryptogram). The utilisation and 
interpretation of proprietary data objects which may be included in this 
response message are outside the scope of these specifications. 


Format 2 shall be used if the response is being returned in a signature as 
specified for the CDA function described in section 6.6 of Book 2. The required 
data elements for the response are shown in the appropriate tables in that 
section. 


For both formats, the Cryptogram Information Data returned by the 
GENERATE AC response message is coded as shown in Table 14: 


Payment System-specific 
cryptogram 


No advice required 


Advice required 


No information given 


Service not allowed 


Table 14: Coding of Cryptogram Information Data 


For the Format 2 response template, if any mandatory data element is missing, 
the terminal shall terminate the transaction. 


6.5.5.5 Processing State Returned in the Response Message 


'9000' indicates a successful execution of the command. 
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6.5.6 GET CHALLENGE Command-Response APDUs 


6.5.6.1 Definition and Scope 


The GET CHALLENGE command is used to obtain an unpredictable number 
from the ICC for use in a security-related procedure. 


The challenge shall be valid only for the next issued command. 


6.5.6.2 Command Message 
The GET CHALLENGE command message is coded as shown in Table 15: 


Not present 
Not present 


Table 15: GET CHALLENGE Command Message 


6.5.6.3 Data Field Sent in the Command Message 


The data field of the command message is not present. 


6.5.6.4 Data Field Returned in the Response Message 


The data field of the response message contains an 8-byte unpredictable number 
generated by the ICC. 


6.5.6.5 Processing State Returned in the Response Message 


'9000' indicates a successful execution of the command. 
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6.5.7 GET DATA Command-Response APDUs 


6.5.7.1 Definition and Scope 


The GET DATA command is used to retrieve a primitive data object not 
encapsulated in a record within the current application. 


The usage of the GET DATA command in this specification is limited to the 
retrieval of the following primitive data objects that are defined in Annex A and 
interpreted by the application in the ICC: 


e ATC (tag '9F36') 

e Last Online ATC Register (tag '9F13') 
e PIN Try Counter (tag '9F17') 

e Log Format (tag '9F4F') 


6.5.7.2 Command Message 
The GET DATA command message is coded as shown in Table 16: 


P1 P2 'OF36'", '9F13', '9F17', or '9F4F" 


Not present 
Not present 
| te joo 


Table 16: GET DATA Command Message 


6.5.7.3. Data Field Sent in the Command Message 


The data field of the command message is not present. 


6.5.7.4 Data Field Returned in the Response Message 


The data field of the response message contains the primitive data object referred 
to in P1 P2 of the command message (in other words, including its tag and its 
length). 

6.5.7.5 Processing State Returned in the Response Message 


'9000' indicates a successful execution of the command. 
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6.5.8 GET PROCESSING OPTIONS Command-Response 
APDUs 


6.5.8.1 Definition and Scope 


The GET PROCESSING OPTIONS command initiates the transaction within the 
ICC. 


The ICC returns the Application Interchange Profile (AIP) and the Application 
File Locator (AFL). 
6.5.8.2 Command Message 


The GET PROCESSING OPTIONS command message is coded as shown in 
Table 17: 


a '‘00'; all other values are RFU 


ba | '‘00'; all other values are RFU 


Data | Processing Options Data Object List 
(PDOL) related data 


Table 17: GET PROCESSING OPTIONS Command Message 


6.5.8.3 Data Field Sent in the Command Message 


The data field of the command message is a data object coded according to the 
PDOL provided by the ICC, as defined in section 5.4, and is introduced by the tag 
'83'. When the data object list is not provided by the ICC, the terminal sets the 
length field of the template to zero. Otherwise, the length field of the template is 
the total length of the value fields of the data objects transmitted to the ICC. 
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6.5.8.4 Data Field Returned in the Response Message 


The data field of the response message consists of a BER-TLV coded data object. 
The coding of the data object shall be according to one of the following two 
formats. 


e Format 1: The data object returned in the response message is a primitive 
data object with tag equal to '80'. The value field consists of the concatenation 
without delimiters (tag and length) of the value fields of the AIP and the AFL. 
The coding of the data object returned in the response message is shown in 
Figure 4: 


Length | Application Interchange | Application File 
Profile Locator 


Figure 4: Format 1 GET PROCESSING OPTIONS Response Message Data Field 


e Format 2: The data object returned in the response message is a constructed 
data object with tag equal to'77'. The value field may contain several BER- 
TLV coded objects, but shall always include the AIP and the AFL. The 
utilisation and interpretation of proprietary data objects which may be 
included in this response message are outside the scope of these 
specifications. 


The AIP specifies the application functions that are supported by the application 
in the ICC and is coded according to Part III. 


The AFL consists of the list, without delimiters, of files and related records for 
the currently selected application that shall be read according to section 10.2. 


For the Format 2 response template, if any mandatory data element is missing, 
the terminal shall terminate the transaction. 


6.5.8.5 Processing State Returned in the Response Message 


'9000' indicates a successful execution of the command. 
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6.5.9 INTERNAL AUTHENTICATE Command-Response 
APDUs 


6.5.9.1 Definition and Scope 


The INTERNAL AUTHENTICATE command initiates the computation of the 
Signed Dynamic Application Data by the card using: 


e the challenge data sent from the terminal and 
e ICC data and 
e arelevant private key stored in the card. 


The ICC returns the Signed Dynamic Application Data to the terminal. 


6.5.9.2 | Command Message 


The INTERNAL AUTHENTICATE command message is coded as shown in 
Table 18: 


Code Value 
CLA | '00' 
INS | '88' 
Pl '00' 
P2 '00' 


Le Length of authentication-related data 
Data | Authentication-related data 
Le '00' 


Table 18: INTERNAL AUTHENTICATE Command Message 


The reference of the algorithm (P1) of the INTERNAL AUTHENTICATE 
command is coded '00', which means that no information is given. The reference 
of the algorithm either is known before issuing the command or is provided in the 
data field. 


6.5.9.3. Data Field Sent in the Command Message 


The data field of the command message contains the authentication-related data 
proprietary to an application. It is coded according to the DDOL as defined in 
Book 2. 
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6.5.9.4 Data Field Returned in the Response Message 


The data field of the response message consists of a BER-TLV coded data object. 
The coding of the data object shall be according to one of the following two 
formats. 


e Format 1: The data object returned in the response message is a primitive 
data object with tag equal to '80'. The value field consists of the value field of 
the Signed Dynamic Application Data as specified in Book 2. 


e Format 2: The data object returned in the response message is a constructed 
data object with tag equal to '77'. The value field may contain several BER- 
TLV coded objects, but shall always include the Signed Dynamic Application 
Data as specified in Book 2. The utilisation and interpretation of proprietary 
data objects which may be included in this response message are outside the 
scope of these specifications. 


For the Format 2 response template, if any mandatory data element is missing, 
the terminal shall terminate the transaction. 

Note: To ensure that the INTERNAL AUTHENTICATE response data length is within 
the 256 byte limit, the length of the Signed Dynamic Application Data plus the length of 


the TLV encoded optional data (if present) shall remain within the limits as specified in 
Book 2 Annex D. 


6.5.9.5 Processing State Returned in the Response Message 


'9000' indicates a successful execution of the command. 
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6.5.10 PIN CHANGE/UNBLOCK Command-Response APDUs 


6.5.10.1 Definition and Scope 


The PIN CHANGE/UNBLOCK command is a post-issuance command. Its 
purpose is to provide the issuer the capability either to unblock the PIN or to 
simultaneously change and unblock the reference PIN. 


Upon successful completion of the PIN CHANGE/UNBLOCK command, the card 
shall perform the following functions: 


e The value of the PIN Try Counter shall be reset to the value of the PIN Try 
Limit. 
e If requested, the value of the reference PIN shall be set to the new PIN value. 


If PIN data is transmitted in the command it shall be enciphered for 
confidentiality. 
Note: The reference PIN, which is stored within the card, is the one that is associated 


with the application and which the card uses to check the Transaction PIN Data 
transmitted within the VERIFY command. 
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6.5.10.2 Command Message 
The PIN CHANGE/UNBLOCK command message is coded as shown in Table 19. 


Value 


'8C' or '84'; coding according to the secure 
messaging specified in Book 2 


'00', '01', or '02' 
Number of data bytes 


Enciphered PIN data component, if present, 
and MAC data component; coding according to 
the secure messaging specified in Book 2 


Not present 


Table 19: PINCHANGE/UNBLOCK Command Message 


P2: If P2 is equal to '00', the reference PIN is unblocked and the PIN Try 
Counter is reset to the PIN Try Limit. There is no PIN update, since the 
PIN CHANGE/UNBLOCK command does not contain a new PIN value. 


The usage of P2 equal to '01' or '02' is reserved for payment systems. 


Any other value of P2 allowing PIN unblocking and/or PIN changing is out 
of the scope of this specification and shall be described for each payment 
system individually. 


6.5.10.3 Data Field Sent in the Command Message 


The data field of the command message contains the PIN data component, if 
present, followed by the MAC data component coded according to the secure 
messaging format specified in Book 2. 


6.5.10.4 Data Field Returned in the Response Message 


No data field is returned in the response message. 


6.5.10.5 Processing State Returned in the Response Message 


'9000' indicates a successful execution of the command. 
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6.5.11 READ RECORD Command-Response APDUs 


6.5.11.1 Definition and Scope 
The READ RECORD command reads a file record in a linear file. 


The response from the ICC consists of returning the record. 


6.5.11.2 Command Message 
The READ RECORD command message is coded as shown in Table 20: 


oe Record number 


[20 | Reference contro parameter eToys 
a 


Table 20: READ RECORD Command Message 


Table 21 defines the reference control parameter of the command message: 


bs | b7 | b6 | b5 | b4 | bs] b2 | b1| Meaning 


28 —_— 
[0 [o [riser nate 


Table 21: READ RECORD Command Reference Control Parameter 


6.5.11.3 Data Field Sent in the Command Message 


The data field of the command message is not present. 
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6.5.11.4 Data Field Returned in the Response Message 


The data field of the response message of any successful READ RECORD 
command contains the record read. For SFIs in the range 1-10, the record is a 
BER-TLV constructed data object as defined in Annex B and coded as shown in 


Figure 5: 


Figure 5: READ RECORD Response Message Data Field 


The response message to READ RECORD for SFIs in the range 11-30 is outside 
the scope of this specification, except as specified in section 10.3 and in Annex D. 


6.5.11.5 Processing State Returned in the Response Message 


'9000' indicates a successful execution of the command. 
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6.5.12 VERIFY Command-Response APDUs 


6.5.12.1 Definition and Scope 


The VERIFY command initiates in the ICC the comparison of the Transaction 
PIN Data sent in the data field of the command with the reference PIN data 
associated with the application. The manner in which the comparison is 
performed is proprietary to the application in the ICC. 


The VERIFY command applies when the Cardholder Verification Method (CVM) 
chosen from the CVM List is an offline PIN, as described in section 10.5. 
6.5.12.2 Command Message 

The VERIFY command message is coded as shown in Table 22: 


Qualifier of the reference data (see Table 23) 


Transaction PIN Data 
Not present 


Table 22: VERIFY Command Message 
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Table 23 defines the qualifier of the reference data (P2): 


Table 23: VERIFY Command qualifier of reference data (P2) 


The processing of the VERIFY command in the ICC will be defined in 
combination with the CVM rules as specified in section 10.5. 


3 The value of P2 = ‘00’ is not used by this specification. 
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The plaintext offline PIN block shall be formatted as follows: 


oD [PPP] [re [rr [reer [ee or lr [eee Te 


where: 


a 
Control field 4 bit binary number with value of 0010 (Hex '2') 


N_ | PIN length 4 bit binary number with permissible values of 0100 to 
1100 (Hex '4' to 'C’) 


PIN digit 4 bit binary number with permissible values of 0000 to 
1001 (Hex '0' to '9') 
PIN/filler Determined by PIN length 
4 bit binary number with a value of 1111 (Hex 'F') 


Table 24: Plaintext Offline PIN Block Format 


P2 = '00' indicates that no particular qualifier is used. The processing of the 
VERIFY command in the ICC should know how to find the PIN data 
unambiguously. 


6.5.12.3 Data Field Sent in the Command Message 


The data field of the command message contains the value field of tag '99'. 


6.5.12.4 Data Field Returned in the Response Message 


No data field is returned in the response message. 


6.5.12.5 Processing State Returned in the Response Message 
'9000' indicates a successful execution of the command. 


When for the currently selected application the comparison between the 
Transaction PIN Data and the reference PIN data performed by the VERIFY 
command fails, the ICC shall return SW2 = 'Cx', where 'x' represents the number 
of retries still possible. When the card returns 'CO'", no more retries are left, and 
the CVM shall be blocked. Any subsequent VERIFY command applied in the 
context of that application shall then fail with SW1 SW2 = '6983'. 
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7 


Files for Financial Transaction Interchange 


The description of the file structure and commands for accessing the files is found 
in Part III of Book 1 (for application selection) and Part II of this book (for the 
application elementary files). The definition of each of the data objects is defined 
in Annex A. 


7.1 


Mapping Data Objects 


The payment system or issuer will map the appropriate data objects to files 
according to their needs, subject to the following restrictions: 


All files accessible using the READ RECORD command as defined in this 
specification containing data objects defined in this specification shall use 
SFIs in the range 1 to 10. These files: 


Shall be linear files readable using the READ RECORD command as 
described in this specification. 


May contain multiple records. Each record is limited to 254 bytes, 
including tag and length. 


Each record shall be coded as a constructed data object. The tag of the 
constructed data object shall be '70' indicating a template proprietary to 
this specification, and the length field shall contain the total length of the 
encapsulated data objects. 


Shall contain only data objects defined in this specification and coded in 
accordance with the BER-TLV described in Annex B. 


May have access conditions to be satisfied for updates, but must be 
readable unconditionally. 


Files with SFIs in the range 11 to 20 are reserved for proprietary data to be 
specified by the individual payment systems. 


Files with SFIs in the range 21 to 30 are reserved for proprietary data to be 
specified by the issuer. 
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e The AFL determines the files and records to be used for processing a 
transaction. The use of the AFL is described in section 10.2. The data objects 
listed in Table 25 are used by the offline data authentication algorithm and, 
when present, should be located in the first record referenced by the AFL.4 


Certification Authority Public Key Index 


| 90" Issuer Public Key Certificate 


Table 25: Data Objects Used by the Offline Data Authentication Algorithm 


Additional information may be found in complementary payment system 
documentation. 


7.2 Mandatory Data Objects 


Table 26 lists the data objects that must be present in the ICC in files read using 
the READ RECORD command. All other data objects defined in this specification 
to be resident in such files in the card are optional. 


'5F24' Application Expiration Date 


'BA' Application Primary Account Number M 
a ae 


Leer. iI Card Risk Management Data | Card Risk Management Data Object List 1_| List 1 


| sp Card Risk Management Data Object List 2 I 


Table 26: Mandatory Data Objects 


Table 27 lists the data objects that must be present if the ICC supports offline 
static data authentication (SDA). Table 28 lists the data objects that must be 
present if the ICC supports offline dynamic data authentication (DDA and/or 
CDA).° Offline data authentication is required to support offline transactions but 
is optional in cards that support only online transactions. 


4 This allows the terminal to optionally perform the hashing necessary for data 
authentication in parallel with reading and parsing of data for other purposes. 


5 The exception may be that the Issuer Public Key Remainder or the ICC Public Key 
Remainder could be absent. This is because if the public key modulus can be recovered in 
its entirety from the public key certificate there is no need for a remainder. 


Page 74 November 2011 


EMV 4.3 Book 3 7 Files for Financial Transaction Interchange 
Application Specification 7.2 Mandatory Data Objects 


Certification Authority Public Key Index 
| 90) Issuer Public Key Certificate 


Signed Static Application Data 
Issuer Public Key Remainder 
'9F32' Issuer Public Key Exponent 


Table 27: Data Required for SDA 


[90 [leruer Publi Kay Carinte 


ICC Public Key Certificate 
ICC Public Key Exponent 
ICC Public Key Remainder 


'9F49' Dynamic Data Authentication Data Object 
List (DDOL) & 


Table 28: Data Required for DDA and/or CDA 


6 In case the DDOL is not present in the card, the Default DDOL shall be used instead. 
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7.3 Data Retrievable by GET DATA Command 


Data objects listed in Table 29 are not retrievable by the READ RECORD 
command but are retrieved by the terminal using the GET DATA command as 
described in this specification. 


Of the objects listed here, only the Application Transaction Counter (ATC) is a 
mandatory data object, and it can be retrieved by either the GET DATA 
command or in the response to a GENERATE AC command. The terminal 
retrieves the ATC via the GET DATA command only if the ICC contains the 
Lower Consecutive Offline Limit (LCOL) and Upper Consecutive Offline Limit 
(UCOL) data objects. If the issuer does not wish terminal velocity checking to be 
performed and omits these data objects, the ICC does not need to support the 
GET DATA command, unless the card supports retrieval of the PIN Try Counter 
or the Log Format using GET DATA. 


'9F36' | Application Transaction Counter (ATC) 
'9F17' | PIN Try Counter i 0 | 


'9F13' | Last Online ATC Register | oo | 


Table 29: Data Objects Retrievable by GET DATA Command 


7.4 Data Retrievable by GET PROCESSING 
OPTIONS 


Data objects listed in Table 30 are not retrievable by the READ RECORD 
command but are retrieved by the terminal using the GET PROCESSING 
OPTIONS command as described in section 6.5.8. Table 30 defines the data 
returned, not the format of the response; section 6.5.8.4 describes the format of 
the data when returned by the GET PROCESSING OPTIONS command. 


Application Interchange Profile 


Application File Locator 


Table 30: Data Retrievable by GET PROCESSING OPTIONS 
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7.5 Erroneous or Missing Data in the ICC 


Data objects in the card are classified in section 7.2 as either mandatory or 
optional. However, some optional data objects must be present to support 
optional functions selected by the issuer or must be present to avoid 
inconsistencies if other related data objects are present. 


When any mandatory data object is missing, the terminal terminates the 
transaction unless otherwise specified in these specifications. When an optional 
data object that is required because of the existence of other data objects or that 
is required to support functions that must be performed due to the setting of bits 
in the Application Interchange Profile is missing, the terminal shall set the ‘ICC 
data missing’ indicator in the Terminal Verification Results (TVR) to 1. 


Table 31 summarises the conditions under which this bit should be set to 1. 

If none of the conditions in Table 31 applies, the terminal shall set the bit to 0. 
The setting of this bit is in addition to any other actions specified in other 
sections of this Book. 


During a transaction the terminal shall ignore any data object coming from the 
ICC which is designated in the EMV data elements dictionary (Table 33 in Annex 
A) as terminal-sourced or issuer-sourced. The data elements dictionary defines 
data as being sourced from any of three places: the ICC, the terminal or the 
issuer. 


The correct formatting of certain card-sourced data objects is not critical for 
completion of a transaction. If during normal processing the terminal recognises 
that any of the following data objects are incorrectly formatted, it may optionally 
ignore the formatting error and continue processing. 


e Cardholder Name ('5F 20") 

e Cardholder Name Extended ('9F0B') 
e Issuer URL ('5F50') 

e Log Entry (‘9F4D') 

e Log Format (‘9F4F') 
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It is up to the issuer to ensure that data in the card 1s of the correct format, and 
no format checking other than that specifically defined is mandated on the part 
of the terminal. However, if in the course of normal processing the terminal 
recognises that data is incorrectly formatted, the terminal shall terminate the 
transaction unless otherwise specified in these specifications. This rule includes 
(but is not limited to): 


Constructed data objects that do not parse correctly. 


Dates that are out of range (for example, months that are not in the range 
1 to 12). 


Other data that must be in a specific range of values but are not. 
Multiple occurrences of a data object that should only appear once. 
An AFL with no entries. 


An AFL entry with invalid syntax, that is, any one or more of the following: 


" An SFI of 0 or 31. 
« A starting record number of 0. 


« An ending record number less than the starting record number 
(byte 3 < byte 2). 


"Number of records participating in offline data authentication greater 
than the number of records (byte 4 > byte 3 - byte 2 + 1). 
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| = Name Tag ‘ICC Data Missing’ Shall Be Set If ... 
Application '9F36' | ATC is not returned by GET DATA command 
Transaction Counter and both Lower and Upper Consecutive Offline 
(ATC) Limit data objects are present 

Cardholder 'SE' Not present and AIP indicates that cardholder 

Verification Method verification is supported 

(CVM) List 

Certification 'SF" Not present and AIP indicates any form of offline 

Authority Public data authentication is supported (SDA, DDA or 


Key Index CDA) 


Issuer Public Key Not present and AIP indicates any form of offline 
Certificate data authentication is supported (SDA, DDA or 
CDA) 


Issuer Public Key '9F32' | Not present and AIP indicates any form of offline 
data authentication is supported (SDA, DDA or 


CDA) 


Issuer Public Key "92! Not present and AIP indicates any form of offline 
Remainder data authentication is supported (SDA, DDA or 
CDA) and the ‘length of the Issuer Public Key’, 


Exponent 


as recovered from the Issuer Public Key 
Certificate, indicates that there was insufficient 
space for the entire Issuer’s Public Key in the 
certificate 


Transaction Counter Upper Consecutive Offline Limits are present 
(ATC) Register 


Signed Static '93! Not present and AIP indicates SDA supported 
Application Data 


ICC Public Key '9F46' | Not present and AIP indicates DDA or CDA 
Certificate supported 

ICC Public Key '9F47' | Not present and AIP indicates DDA or CDA is 
Exponent supported 


ICC Public Key '9F48' | Not present and AIP indicates DDA or CDA is 
Remainder supported and the ‘length of the ICC Public Key’, 
as recovered from the ICC Public Key 


Last Online '9F13' | Last Online ATC Register is not returned by 
Application GET DATA command and both Lower and 


Certificate, indicates that there was insufficient 
space for the entire ICC’s Public Key in the 
certificate 


Table 31: ICC Data Missing Indicator Setting 
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The Application Interchange Profile specifies the application functions that are 
supported by the card. The terminal shall attempt to execute only those functions 
that the ICC supports. The functions shall be performed according to the 
Conditions of Execution as specified in section 10. 


Book 1 describes all functionality outside the application layer, including the 
selection of the application. The functions described here begin after application 
selection has taken place. 


The remainder of this book deals with the terminal-to-ICC dialogue on the level 
of the application logical functions. Section 8.2 describes a possible transaction 
flow. 


8.1 Exception Handling 


Exceptions to normal processing are described in this Book for specific status 
codes returned in the status bytes (SW1, SW2) or for missing data. Unless 
otherwise specified in these specifications, any SW1 SW2 returned by the 
transport layer to the application layer other than '9000', '63Cx', or '6283' shall 
cause termination of the transaction.? This requirement applies throughout 
these specifications except for the Application Selection process described in 
Book 1. 


8.2 Example Flowchart 


The flowchart in Figure 6 gives an example of a transaction flow that may be 
used by a terminal for a normal purchase transaction. This flowchart is only an 
example, and the order of processing may differ from that given here. All 
restrictions on the order of processing are provided in section 10. 


7 Other actions may be taken by prior agreement but are outside the scope of this 
specification. 
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Figure 6: Transaction Flow Example 
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8.3 Additional Functions 


Provision has been made in this specification for additional functions beyond 
those described here. Such additional functions may be: 


e future additions to this specification 


e proprietary functions implemented by local or national agreement or by the 
individual payment systems 


The Application Interchange Profile indicates the functions supported in the ICC 
according to this specification. Most of the bits in this data object are reserved for 
future use (RFU). When a new function is added, a bit in the Application 
Interchange Profile will be allocated to indicate support for the new function, and 
this specification will be updated to specify the new function and where it fits 
into the transaction flow. 


Proprietary functions may be added to the terminal and the ICC application as 
long as they do not interfere with processing of terminals and ICCs not 
implementing the function. For example, offline dynamic data authentication 
based on symmetric keys may be added at local option. Such proprietary 
functions, while not described in this specification, are not precluded, as long as 
the functions specified herein continue to be supported for all ICCs, including 
those not implementing the proprietary functions. 
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The GENERATE AC command format and response codes are described fully in 
section 6.5.5. This section describes how the various options and data elements 
are used in transaction processing. Figure 7 depicts the interaction between the 
terminal decisions, ICC decisions, issuer approval, the GENERATE AC 
command, and the possible ICC responses. 


The complete transaction flow is not shown in this chart, only the GENERATE 
AC commands, responses, and associated decisions. 
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Figure 7: Use of GENERATE AC Options 
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9.1 Command Parameters 


The GENERATE AC command parameters provide three different options to the 
terminal: 


e Request for the generation of a TC 
e Request for the generation of an ARQC 
e Request for the generation of an AAC 


9.2 Command Data 


The data field of the GENERATE AC command is not TLV encoded, so it is 
imperative that the ICC knows the format of this data when the command is 
received. This is achieved by allowing the ICC to specify the format of the data to 
be included in the GENERATE AC command using a Card Risk Management 
Data Object List (CDOL). 


9.2.1 Card Risk Management Data 


The CDOL is a data object in the ICC that provides to the terminal a list of data 
objects that must be passed from the terminal to the ICC in the GENERATE AC 
command. There shall be two CDOLs in the ICC, referred to as CDOL1 (tag '8C’') 
and CDOL2 (tag '8D'). CDOL1 is used with the first GENERATE AC command, 
and CDOL2 is used with the second GENERATE AC command (if used). The 
terminal uses the appropriate CDOL and the rules specified in section 5.4 to 
build the appropriate data field for the command. It is the responsibility of the 
terminal to ensure that current data is used in building the GENERATE AC 
command. To this end, the command data should be built immediately prior to 
issuing the GENERATE AC command. 
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9.2.2 Transaction Certificate Data 


A CDOL may request a TC Hash Value to be included in the command data of a 
GENERATE AC command. The TDOL is a data object that provides to the 
terminal a list of data objects to be used in generating the TC Hash Value. The 
ICC may contain the TDOL, but there may be a default TDOL in the terminal, 
specified by the payment system, for use in case the TDOL is not present in the 
ICC. To create the hash value, the terminal shall use the TDOL (if present) or 
the default TDOL to create the appropriate value for input to the hash algorithm, 
applying the rules specified in section 5.4. If the default TDOL is used, the 
terminal shall set the ‘Default TDOL used’ bit in the TVR to 1. If a default TDOL 
is required but is not present in the terminal, a default TDOL with no data 
objects in the list shall be assumed. If this event occurs, since the default TDOL 
was not used, the terminal shall not set the ‘Default TDOL Used’ bit in the TVR 
to 1. 


If the terminal issues a second GENERATE AC command during the processing 
of a transaction, the terminal shall ensure that the data provided in the TC Hash 
Value is current at the time the command is issued. 


9.3 Command Use 


Either one or two GENERATE AC commands are issued during the processing of 
a transaction according to this specification. 


The ICC shall respond to the first GENERATE AC command with any of the 
following: 


e TC 
ARQC 
AAC 


The ICC shall respond to a second GENERATE AC command with either a TC or 
an AAC. 


The possible responses listed above are in hierarchical order, with a TC being the 
highest and an AAC being the lowest. The terminal may request a TC, an ARQC, 
or an AAC. If the ICC responds with a cryptogram at a higher level or with a 
cryptogram of an undefined type, this indicates a logic error in the ICC. If this 
occurs after the first GENERATE AC command in a transaction, the transaction 
shall be terminated. If it occurs after the second GENERATE AC command, all 
processing for the transaction has been completed, and the cryptogram returned 
shall be treated as an AAC. 


If the ICC response is an approval (TC) or online authorisation request (ARQC) 
and the ‘CDA signature requested’ bit in the GENERATE AC command is 1, the 
ICC shall return the GENERATE AC response in a public key signature as 
specified in Book 2 section 6.6. 
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9.3.1 GENERATE AC (First Issuance) 


The terminal completes its online/offline decision process with a GENERATE AC 
command (see section 6.5.5). The form of the command depends upon the decision 
made by the terminal: 


e Ifthe terminal decides the transaction might be completed offline, it requests 
a TC from the ICC. The ICC shall reply with a TC, an ARQC, or an AAC, 
depending upon its own analysis of the transaction. 


e Ifthe terminal decides the transaction should go online, it requests an ARQC 
from the ICC. The ICC shall reply with an ARQC, or an AAC. 


e Ifthe terminal decides to reject the transaction, it requests an AAC from the 
ICC. The ICC shall reply with an AAC. 


If the ICC responds with a TC or an AAC, the terminal completes the transaction 
offline. 


If the ICC responds with an ARQC, the terminal attempts to go online, sending 
an authorisation request message to the issuer. Included in the authorisation 
request message is the ARQC for online card authentication. 


9.3.2 GENERATE AC (Second Issuance) 


Whether the terminal receives an authorisation response message as a result of 
online processing or an approval or rejection by using the Issuer Action Code - 
Default, it completes the transaction by requesting either a TC (in the case an 
approval was obtained) or an AAC (in case the issuer’s instruction is to reject the 
transaction) from the ICC. If a TC was requested, the ICC shall reply with either 
a TC or an AAC. If an AAC was requested, the card shall reply with an AAC. 


The ICC shall permit at most two GENERATE AC commands in a transaction. If 
the terminal issues more than two, the third and all succeeding GENERATE AC 
commands shall end with SW1 SW2 = '6985', and no cryptogram shall be 
returned. 
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10 Functions Used in Transaction Processing 


The following sections shall be read in conjunction with Book 4, Part II, which 
may contain additional terminal-specific requirements. 


10.1 Initiate Application Processing 


Purpose: 

The Initiate Application Processing function: 

e informs the ICC that the processing of a new transaction is beginning 

e provides to the ICC the terminal-related information about the transaction 


e obtains from the ICC the Application Interchange Profile and a list of files 
that contain the ICC data to be used in processing the transaction 


e determines whether the transaction is allowed 
Conditions of Execution: 

The terminal shall always execute this function. 

Sequence of Execution: 

This is the first function performed after Application Selection. 
Description: 


The terminal shall set all bits in the Transaction Status Information (TSI) and 
the Terminal Verification Results (TVR) to 0.8 


The PDOL is a list of tags and lengths of terminal-resident data elements needed 
by the ICC in processing the GET PROCESSING OPTIONS command. Only data 
elements having the terminal as the source of the data may be referenced in the 
PDOL. 


If the PDOL does not exist, the GET PROCESSING OPTIONS command uses a 
command data field of '8300', indicating that the length of the value field in the 
command data is zero. 


If the PDOL exists, the terminal extracts the PDOL from the FCI of the ADF and 
uses it to create a concatenated list of data elements without tags or lengths. The 
rules specified in section 5.4 apply to processing of the PDOL. 


8 There may be some exceptions in the timing for this. For example, these bits could be 
set to 0 at the completion of the previous transaction or prior to application selection of 
this transaction. The intent here is that the processing steps as described in the 
Application Specification presume the bits have been initialised to 0. 
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The terminal issues the GET PROCESSING OPTIONS command using either 
the command data field of '8300' Gf there was no PDOL in the ICC) or a data 
object constructed with a tag of '83' and the appropriate length according to 
BER-TLV encoding rules and a value field that is the concatenated list of data 
elements resulting from processing the PDOL. The card returns either: 


e The Application Interchange Profile, the Application File Locator (identifying 
the files and records containing the data to be used for the transaction), and 
status SW1 SW2 = '9000'" or 


e Status SW1 SW2 ='6985' (Conditions of use not satisfied’), indicating that 
the transaction cannot be performed with this application. 


The format of the response message is given in section 6.5.8. 


If the status words '6985' are returned, the terminal shall eliminate the current 
application from consideration and return to the Application Selection function to 
select another application. 
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10.2 Read Application Data 


Purpose: 


Data contained in files in the ICC are required by the terminal to perform the 
various functions used in transaction processing as described in this section. The 
terminal must read this data from the ICC. 


Conditions of Execution: 
The terminal shall always execute this function. 
Sequence of Execution: 


The Read Application Data function is performed immediately following the 
Initiate Application Processing function. 


Description: 


The terminal shall read the files and records indicated in the AFL using the 
READ RECORD command identifying the file by its SFI. If an error prevents the 
terminal from reading data from the ICC, the transaction shall be terminated 
(see section 8.1). 


The AFL is a list identifying the files and records to be used in the processing of a 
transaction. The terminal is to read only the records named in the AFL. Each 
element of the list corresponds to a file to be read and is structured as follows: 


e The five most significant bits of the first byte indicate the SFI. The three least 
significant bits of the first byte shall be set to zero. 


e The second byte indicates the first (or only) record number to be read for that 
SFI. The second byte shall never be set to zero. 


e The third byte indicates the last record number to be read for that SFI. Its 
value is either greater than or equal to the second byte. When the third byte 
is greater than the second byte, all the records ranging from the record 
number in the second byte to and including the record number in the third 
byte shall be read for that SFI. When the third byte is equal to the second 
byte, only the record number coded in the second byte shall be read for that 
SFI. 


e The fourth byte indicates the number of records involved in offline data 
authentication starting with the record number coded in the second byte. The 
fourth byte may range from zero to the value of the third byte less the value 
of the second byte plus 1. 
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The terminal shall process each entry in the AFL from left to right. A READ 
RECORD command as described in section 6.5.11 shall be issued for each record 
between the starting record number and the ending record number, inclusively. 
Any SW1 SW2 other than '9000' passed to the application layer as a result of 
reading any record shall cause the transaction to be terminated. Records 
specified in the AFL to be included in offline data authentication shall be 
processed as described in section 10.3. 


The terminal shall store all recognised data objects read, whether mandatory or 
optional, for later use in the transaction processing. Data objects that are not 
recognised by the terminal (that is, their tags are unknown by the terminal) shall 
not be stored, but records containing such data objects may still participate in 
their entirety in offline data authentication, depending upon the coding of the 
AFL.? 


All mandatory data objects shall be present in the card. If any mandatory data 
objects are not present, the terminal shall terminate the transaction. 


Redundant primitive data objects are not permitted. If the terminal encounters 
more than one occurrence of a single primitive data object while reading data 
from the ICC, the transaction shall be terminated. 


Proprietary data files may or may not conform to this specification. Records in 
proprietary files may be represented in the AFL and may participate in offline 
data authentication if they are readable without conditions by the READ 
RECORD command coded according to this specification. Otherwise, the reading 
and processing of proprietary files is beyond the scope of this specification. 


9 Payment system-specific tags are interpreted within the context of the application RID. 
Issuer-specific tags are interpreted within the context of the Issuer Identification Number 
(as defined in ISO/IEC 7812-1). Additionally, to satisfy business requirements such as 
proprietary domestic processing, multiple issuers may agree on the definition of a private 
class tag. Such tags may be interpreted in the context of other data such as Issuer 
Country Code. 
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10.3 Offline Data Authentication 


Purpose: 


Offline data authentication is performed as specified in Book 2. This specification 
describes how it is determined whether offline data authentication will be 
performed, what kind of authentication will be performed, and how the success or 
failure of authentication affects the transaction flow and data recorded in the 
TVR and TSI. 


Conditions of Execution: 


Availability of data in the ICC to support offline data authentication is optional; 
its presence is indicated in the Application Interchange Profile. If the terminal 
and the ICC support a common method of offline data authentication, the 
terminal shall perform offline data authentication. Depending on the capabilities 
of the card and the terminal, SDA or DDA or CDA is performed. 


If both of the following are true, the terminal shall perform CDA as specified in 
Book 2: 


e The Application Interchange Profile indicates that the card supports CDA. 
e The terminal supports CDA. 


If all of the following are true, the terminal shall perform DDA as specified in 
Book 2: 


e The Application Interchange Profile indicates that the card supports DDA. 
e The terminal supports DDA. 
e Either the card or terminal (or both) does not support CDA. 


If all of the following are true, the terminal shall perform SDA as specified in this 
specification: 


e The Application Interchange Profile indicates that the card supports SDA. 
e The terminal supports SDA. 

e Either the card or the terminal (or both) does not support DDA. 

e Either the card or terminal (or both) does not support CDA. 


If neither SDA nor DDA nor CDA is performed, the terminal shall set the ‘Offline 
data authentication was not performed’ bit in the TVR to 1. 


Sequence of Execution: 


The terminal shall perform offline data authentication in any order after Read 
Application Data but before completion of the terminal action analysis. 
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Note: Although the terminal shall commence performing CDA before completion of 
Terminal Action Analysis, the terminal will not normally finish performing CDA until 
after it has received the response to the GENERATE AC command. (This is a necessary 
consequence of the design of CDA.) 


Description: 


SDA authenticates static data put into the card by the issuer. DDA and CDA 
authenticate ICC-resident data, data from the terminal, and the card itself. 


Input to the authentication process is formed from the records identified by the 
AFL, followed by the data elements identified by the optional Static Data 
Authentication Tag List (tag '9F4A‘). 


Only those records identified in the AFL as participating in offline data 
authentication are to be processed. Records are processed in the same sequence 
in which they appear within AFL entries. The records identified by a single AFL 
entry are to be processed in record number sequence. The first record begins the 
input for the authentication process, and each succeeding record is concatenated 
at the end of the previous record. 


The records read for offline data authentication shall be TLV-coded with tag 
equal to '70'. 


The data from each record to be included in the offline data authentication input 
depends upon the SFI of the file from which the record was read. 


e For files with SFI in the range 1 to 10, the record tag ('70') and the record 
length are excluded from the offline data authentication process. All other 
data in the data field of the response to the READ RECORD command 
(excluding SW1 SW2) is included. 


e For files with SFI in the range 11 to 30, the record tag ('70') and the record 
length are not excluded from the offline data authentication process. Thus all 
data in the data field of the response to the READ RECORD command 
(excluding SW1 SW2) is included. 


If the records read for offline data authentication are not TLV-coded with tag 
equal to '70' then offline data authentication shall be considered to have been 
performed and to have failed; that is, the terminal shall set the ‘Offline data 
authentication was performed’ bit in the TSI to 1, and shall set the appropriate 
‘SDA failed’ or ‘DDA failed’ or ‘CDA failed’ bit in the TVR. 


The bytes of the record are included in the concatenation in the order in which 
they appear in the command response. 


After all records identified by the AFL have been processed, the Static Data 
Authentication Tag List is processed, if it exists. If the Static Data 
Authentication Tag List exists, it shall contain only the tag for the Application 
Interchange Profile. The tag must represent the AIP available in the current 
application. The value field of the AIP is to be concatenated to the current end of 
the input string. The tag and length of the AIP are not included in the 
concatenation. 
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Building of the input list for offline data authentication is considered the first 
step in the offline data authentication process. If the input cannot be built 
because of a violation of one of the above rules but offline data authentication 
should be performed according to the ‘Conditions of Execution’ above, offline data 
authentication shall be considered to have been performed and to have failed; 
that is, the terminal shall set the ‘Offline data authentication was performed’ bit 
in the TSI to 1 and shall set the appropriate ‘SDA failed’ or ‘DDA failed’ or ‘CDA 
failed’ bit in the TVR. 


See Book 2 for additional steps to be performed for offline data authentication. 


If SDA is performed but is unsuccessful, the ‘SDA failed’ bit in the TVR shall be 
set to 1; otherwise it shall be set to 0. 


If DDA is performed but is unsuccessful, the ‘DDA failed’ bit in the TVR shall be 
set to 1; otherwise it shall be set to 0. 


If CDA is performed but is unsuccessful, the ‘CDA failed’ bit in the TVR shall be 
set to 1; otherwise it shall be set to 0. 


Upon completion of the offline data authentication function, the terminal shall 
set the ‘Offline data authentication was performed’ bit in the TSI to 1. 


November 2011 Page 97 


10 Functions Used in Transaction Processing EMV 4.3 Book 3 
10.4 Processing Restrictions Application Specification 


10.4 Processing Restrictions 


Purpose: 


The purpose of the Processing Restrictions function is to determine the degree of 
compatibility of the application in the terminal with the application in the ICC 
and to make any necessary adjustments, including possible rejection of the 
transaction. 


Conditions of Execution: 
The terminal shall always execute this function. 
Sequence of Execution: 


Functions described here may be performed at any time after Read Application 
Data and prior to completion of the terminal action analysis. 


Description: 


The Processing Restrictions function comprises the following compatibility 
checks: 


e Application Version Number 
e Application Usage Control 
e Application Effective/Expiration Dates Checking 


10.4.1 Application Version Number 


The application within both the terminal and the ICC shall maintain an 
Application Version Number assigned by the payment system. The terminal shall 
use the version number in the ICC to ensure compatibility. If the Application 
Version Number is not present in the ICC, the terminal shall presume the 
terminal and ICC application versions are compatible, and transaction 
processing shall continue. If the Application Version Number is present in the 
ICC, it shall be compared to the Application Version Number maintained in the 
terminal. If they are different, the terminal shall set the ‘ICC and terminal have 
different application versions’ bit in the TVR to 1. 


10.4.2 Application Usage Control 


The Application Usage Control indicates restrictions limiting the application 
geographically or to certain types of transactions. If this data object is present, 
the terminal shall make the following checks: 


e Ifthe transaction is being conducted at an ATM, the ‘Valid at ATMs’ bit must 
be on in Application Usage Control. 


e Ifthe transaction is not being conducted at an ATM, the ‘Valid at terminals 
other than ATMs’ bit must be on in Application Usage Control. 
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If the Application Usage Control and Issuer Country Code are both present in the 
ICC, the terminal shall make the checks described in Table 32. 


then the following bit must be 


and if . 
Issuer Country Code: Selto Lm 
y . Application Usage Control: 
Transaction Type | matches ‘Valid for domestic cash 
indicates cash Terminal Country Code _ | transactions’ 
paneacoe does not match ‘Valid for international cash 


Terminal Country Code _ | transactions’ 


Transaction Type | matches ‘Valid for domestic goods’ and/or 

indicates Terminal Country Code _ | ‘Valid for domestic services’ 

per i ve ) does not match ‘Valid for international goods’ 

Bente ee ae Terminal Country Code | and/or ‘Valid for international 
services’ 

transaction hasa_ | matches ‘Domestic cashback allowed’ 


cashback amount | Terminal Country Code 


does not match ‘International cashback allowed’ 
Terminal Country Code 


Table 32: Terminal Action Regarding Application Usage Control 


If any of the above tests fail, the terminal shall set the ‘Requested service not 
allowed for card product’ bit in the TVR to 1. 


10.4.3 Application Effective/Expiration Dates Checking 


If the Application Effective Date is present in the ICC, the terminal shall check 
that the current date is greater than or equal to the Application Effective Date. If 
it is not, the terminal shall set the ‘Application not yet effective’ bit in the TVR 

to 1. 


The terminal shall check that the current date is less than or equal to the 
Application Expiration Date. If it is not, the terminal shall set the ‘Expired 
application’ bit in the TVR to 1. 
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10.5 Cardholder Verification 


Purpose: 


Cardholder verification is performed to ensure that the person presenting the 
ICC is the person to whom the application in the card was issued. 


Conditions of Execution: 


Ability of the ICC to support at least one cardholder verification method is 
indicated in the Application Interchange Profile, as shown in Annex C1. If this 
bit is set to 1, the terminal shall use the cardholder verification related data in 
the ICC to determine whether one of the issuer-specified cardholder verification 
methods (CVMs) shall be executed. This process is described below. 


Sequence of Execution: 


This function may be performed any time after Read Application Data and before 
completion of the terminal action analysis. 


Description: 
The CVM List (tag '8E') is a composite data object consisting of the following: 


1. An amount field (4 bytes, binary format), referred to as ‘*X’ in Table 40: CVM 
Condition Codes. ‘X’ is expressed in the Application Currency Code with 
implicit decimal point. For example, 123 (hexadecimal '7B') represents £1.23 
when the currency code is '826'. 


2. Asecond amount field (4 bytes, binary format), referred to as ‘Y in Table 40. 
‘Y’ is expressed in Application Currency Code with implicit decimal point. For 
example, 123 (hexadecimal '7B') represents £1.23 when the currency code is 
'826'. 

3. A variable-length list of two-byte data elements called Cardholder 
Verification Rules (CV Rules). Each CV Rule describes a CVM and the 
conditions under which that CVM should be applied (see Annex C3). 


If the CVM List is not present in the ICC, the terminal shall terminate 
cardholder verification without setting the ‘Cardholder verification was 
performed’ bit in the TSI. 


Note: A CVM List with no Cardholder Verification Rules is considered to be the same as 
a CVM List not being present. 


If the CVM List is present in the ICC, the terminal shall process each rule in the 
order in which it appears in the list according to the following specifications. 
Cardholder verification is completed when any one CVM is successfully 
performed or when the list is exhausted. 


If the terminal encounters formatting errors in the CVM List such as a list with 
an odd number of bytes (that is, with an incomplete CVM Rule), the terminal 
shall terminate the transaction as specified in Book 3 section 7.5. 
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If any of the following is true: 
e the conditions expressed in the second byte of a CV Rule are not satisfied, or 


e data required by the condition (for example, the Application Currency Code or 
Amount, Authorised) is not present, or 


e the CVM Condition Code is outside the range of codes understood by the 
terminal (which might occur if the terminal application program is at a 
different version level than the ICC application), 


then the terminal shall bypass the rule and proceed to the next. If there are no 
more CV Rules in the list, cardholder verification has not been successful, and 

the terminal shall set the ‘Cardholder verification was not successful’ bit in the 
TVR to 1. 


If the conditions expressed in the second byte of the CV Rule are satisfied, the 
terminal next checks whether it recognises the CVM coded in the first byte of the 
CV Rule and proceeds according to the following steps: 


1. Ifthe CVM is recognised, the terminal next checks to determine whether it 
supports the CVM. 


e Ifthe CVM is supported, the terminal shall attempt to perform it. 


o Ifthe CVM is performed successfully, cardholder verification is 
complete and successful. If the CVM just processed was ‘Fail CVM 
Processing’, the terminal shall set the ‘Cardholder verification was 
not successful’ bit in the TVR (b8 of byte 3) to 1 and no further 
CVMs shall be processed regardless of the setting of b7 of byte 1 in 
the first byte of the CV Rule.?!° 


o Ifthe CVM is not performed successfully, processing continues at 
step 2. 


e Ifthe CVM is not supported, processing continues at step 2. In addition, 
the terminal shall set the ‘PIN entry required and PIN pad not present or 
not working’ bit (b5 of byte 3) of the TVR to 1 for the following cases: 


o The CVM was online PIN and online PIN was not supported 


o The CVM included any form of offline PIN, and neither form of 
offline PIN was supported. 


If the CVM is not recognised, the terminal shall set the ‘Unrecognised CVM’ 
bit in the TVR (b7 of byte 3) to 1 and processing continues at step 2. 


2. If cardholder verification was not completed in step 1 (that is, the CVM was 
not recognised, was not supported, or failed), the terminal examines b7 of 
byte 1 of the CV Rule. 


10 If a card CVM List contains an entry for 'Fail CVM Processing,’ it is strongly 
recommended that byte 1 bit 7 be set to 0 for this entry. 
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e Ifb7is set to 1, processing continues with the next CV Rule, if one is 
present. 


e Ifb7 is set to 0, or there are no more CV Rules in the list, cardholder 
verification is complete and unsuccessful. The terminal shall set the 
‘Cardholder verification was not successful’ bit in the TVR (b8 of byte 3) to 
1. 


When cardholder verification is completed, the terminal shall: 
e set the CVM Results according to Book 4 section 6.3.4.5 
e set the ‘Cardholder verification was performed’ bit in the TSI to 1. 
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10.5.1 Offline PIN Processing 


This section applies to the verification by the ICC of a plaintext or enciphered 
PIN presented by the terminal. 


If an offline PIN is the selected CVM as determined by the above process, offline 
PIN processing may not be successfully performed for any one of the following 
reasons: 


e The terminal does not support offline PIN." In this case, the terminal shall 
set the ‘PIN entry required and PIN pad not present or not working’ bit in the 
TVR to 1. 


e The terminal supports offline PIN, but the PIN pad is malfunctioning. In this 
case, the terminal shall set the ‘PIN entry required and PIN pad not present 
or not working’ bit in the TVR to 1. 


e The terminal bypassed PIN entry at the direction of either the merchant or 
the cardholder.!2 In this case, the terminal shall set the ‘PIN entry required, 
PIN pad present, but PIN was not entered’ bit in the TVR to 1. The terminal 
shall consider this CVM unsuccessful and shall continue cardholder 
verification processing in accordance with the card’s CVM List. 


e The PIN is blocked upon initial use of the VERIFY command or if recovery of 
the enciphered PIN Block has failed (the ICC returns SW1 SW2 = '6983' or 
'6984' in response to the VERIFY command). In this case, the terminal shall 
set the ‘PIN Try Limit exceeded’ bit in the TVR to 1. 


e The number of remaining PIN tries is reduced to zero (indicated by an 
SW1 SW2 of '63CO0' in the response to the VERIFY command). In this case, 
the terminal shall set the ‘PIN Try Limit exceeded’ bit in the TVR to 1. 


The only case in which offline PIN processing is considered successful is when 
the ICC returns an SW1 SW2 of '9000' in response to the VERIFY command. 


11 This means that the terminal does not support either offline plaintext PIN verification 
or offline enciphered PIN verification. If the terminal supports at least one of these 
functions, it is considered to support offline PIN for the purposes of setting the TVR bits. 


12 Especially for a new cardholder or during conversion to PINs, it is likely that a 
cardholder will realize that he or she does not know the PIN. In this case, it is better to 
bypass PIN processing with an indication to the issuer of the circumstances than it is to 
either terminate the transaction or try numbers until the PIN try count is exhausted. If 
the transaction goes online, the issuer can decide whether to accept the transaction 
without the PIN. 


November 2011 Page 103 


10 Functions Used in Transaction Processing EMV 4.3 Book 3 
10.5 Cardholder Verification Application Specification 


10.5.2 Online PIN Processing 


If online PIN processing is a required CVM as determined by the above process, 
the processing may not be successfully performed for any one of the following 
reasons: 


e The terminal does not support online PIN. In this case, the terminal shall set 
the ‘PIN entry required and PIN pad not present or not working’ bit in the 
TVR to 1. 


e The terminal supports online PIN, but the PIN pad is malfunctioning. In this 
case, the terminal shall set the ‘PIN entry required and PIN pad not present 
or not working’ bit in the TVR to 1. 


e The terminal bypassed PIN entry at the direction of either the merchant or 
the cardholder. In this case, the terminal shall set the ‘PIN entry required, 
PIN pad present, but PIN was not entered’ bit in the TVR to 1. 


If the online PIN is successfully entered, the terminal shall set the ‘Online PIN 
entered’ bit in the TVR to 1. In this case, cardholder verification is considered 
successful and complete. 


10.5.3 Signature Processing 


If a (paper) signature is a required CVM as determined by the above process, the 
terminal shall determine success based upon the terminal’s capability to support 
the signature process (see complementary payment systems documentation for 
additional information). If the terminal is able to support signature, the process 
is considered successful, and cardholder verification is complete. 


10.5.4 Combination CVMs 


Some CVMs require multiple verification methods (for example, offline PIN plus 
signature). For these CVMs, all methods in the CVM must be successful for 
cardholder verification to be considered successful. 


10.5.5 CVM Processing Logic 


The flows on the following pages illustrate the CVM processing logic but do not 
contain all the details of the execution of the selected CVM. 
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10.6 Terminal Risk Management 


Purpose: 


Terminal risk management is that portion of risk management performed by the 
terminal to protect the acquirer, issuer, and system from fraud. It provides 
positive issuer authorisation for high-value transactions and ensures that 
transactions initiated from ICCs go online periodically to protect against threats 
that might be undetectable in an offline environment. The result of terminal risk 
management is the setting of appropriate bits in the TVR. 


Conditions of Execution: 


Terminal risk management shall always be performed regardless of the setting of the 
‘Terminal risk management is to be performed’ bit in the Application Interchange Profile. 
Random transaction selection need not be performed by a terminal with no online 
capability. 


Sequence of Execution: 


Terminal risk management may be performed at any time after Read Application 
Data but before issuing the first GENERATE AC command. 


Description: 

Terminal risk management consists of: 
e Floor limit checking 

e Random transaction selection 

e Velocity checking 


Upon completion of terminal risk management, the terminal shall set the 
‘Terminal risk management was performed’ bit in the TSI to 1. 
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10.6.1 Floor Limits 


To prevent split sales, the terminal may have a transaction log of approved 
transactions stored in the terminal consisting of at least the Application PAN 
and transaction amount and possibly the Application PAN Sequence Number and 
Transaction Date. The number of transactions to be stored and maintenance of 
the log are outside the scope of this specification, although to prevent split sales 
the number of transactions stored may be quite small. 


During terminal risk management floor limit checking, the terminal checks the 
transaction log (if available) to determine if there is a log entry with the same 
Application PAN, and, optionally, the same Application PAN Sequence Number. 
If there are several log entries with the same PAN, the terminal selects the most 
recent entry. The terminal adds the Amount, Authorised for the current 
transaction to the amount stored in the log for that PAN to determine if the sum 
exceeds the Terminal Floor Limit. If the sum is greater than or equal to the 
Terminal Floor Limit, the terminal shall set the ‘Transaction exceeds floor limit’ 
bit in the TVR to 1. 


If the terminal does not have a transaction log available or if there is no log entry 
with the same PAN, the Amount, Authorised is compared to the appropriate floor 
limit. If the amount authorised is equal to or greater than the floor limit, the 
terminal sets the “Transaction exceeds floor limit’ bit to 1 in the TVR. 


10.6.2 Random Transaction Selection 


For each application the relevant payment system specifies, in addition to the 
floor limit: 


e ‘Target Percentage to be Used for Random Selection’ (in the range of 0 to 99) 


e Threshold Value for Biased Random Selection (which must be zero or a 
positive number less than the floor limit) 


e ‘Maximum Target Percentage to be Used for Biased Random Selection’ (also 
in the range of 0 to 99 but at least as high as the previous “Target Percentage 
to be Used for Random Selection’). This is the desired percentage of 
transactions ‘Just below’ the floor limit that will be selected by this algorithm. 


Any transaction with a transaction amount less than the Threshold Value for 
Biased Random Selection will be subject to selection at random without further 
regard for the value of the transaction. The terminal shall generate a random 
number in the range of 1 to 99. If this random number is less than or equal to the 
‘Target Percentage to be used for Random Selection’, the transaction shall be 
selected. 
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Any transaction with a transaction amount equal to or greater than the 
Threshold Value for Biased Random Selection but less than the floor limit will be 
subject to selection with bias toward sending higher value transactions online 
more frequently (biased random selection). For these transactions, the terminal 
shall compare its generated random number against a Transaction Target 
Percent, which is a linear interpolation of the target percentages provided by the 
payment system (‘Target Percentage to be used for Random Selection’ and 
‘Maximum Target Percentage to be used for Biased Random Selection’).!° If the 
random number is less than or equal to the Transaction Target Percent, the 
transaction shall be selected. 


Figure 13 illustrates the probability of selection as a function of the transaction 
amount: 
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Figure 13: Random Transaction Selection Example 


If the transaction is selected through the process described in this section, the 
terminal shall set the “Transaction selected randomly for online processing’ bit in 
the TVR to 1. 


13 The Transaction Target Percent is calculated as follows: 


Amount, Authorised — Threshold Value 
Floor Limit — Threshold Value 


Interpolation factor = 


Transaction Target Percent = ((Maximum Target Percent - Target Percent) x Interpolation factor) 


+ Target Percent 
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10.6.3 Velocity Checking 


If both the Lower Consecutive Offline Limit (tag '9F14') and Upper Consecutive 
Offline Limit (tag '9F23') exist, the terminal shall perform velocity checking as 
described in this section. '* If either of these data objects is not present in the ICC 
application, the terminal shall skip this section. 


The ATC and Last Online ATC Register shall be read from the ICC using 
GET DATA commands. If either of the required data objects is not returned by 
the ICC in response to the GET DATA command, or if the value of the ATC is 
less than or equal to the value in the Last Online ATC Register, the terminal 
shall: 


e Set both the ‘Lower consecutive offline limit exceeded’ and the ‘Upper 
consecutive offline limit exceeded’ bits in the TVR to 1. 


e Not set the ‘New card’ indicator in the TVR unless the Last Online ATC 
Register is returned and equals zero. 


e End velocity checking for this transaction. 


If the required data objects are available, the terminal shall compare the 
difference between the ATC and the Last Online ATC Register with the Lower 
Consecutive Offline Limit to see if the limit has been exceeded. If the difference is 
equal to the Lower Consecutive Offline Limit, this means that the limit has not 
yet been exceeded. If the limit has been exceeded, the terminal shall set the 
‘Lower consecutive offline limit exceeded’ bit in the TVR to 1 and also compare 
the difference with the Upper Consecutive Offline Limit to see if the upper limit 
has been exceeded. If it has, the terminal shall set the ‘Upper consecutive offline 
limit exceeded’ bit in the TVR to 1. 


The terminal shall also check the Last Online ATC Register for a zero value. If it 
is zero, the terminal shall set the ‘New card’ bit in the TVR to 1. 


14 The purpose of velocity checking is to allow an issuer to request that, after a certain 
number of consecutive offline transactions (the Lower Consecutive Offline Limit), 
transactions should be completed online. However, if the terminal is incapable of going 
online, transactions may still be completed offline until a second (Upper Consecutive 
Offline Limit) limit is reached. After the upper limit is reached, the recommendation of 
the issuer might be to reject any transaction that cannot be completed online. Once a 
transaction has been completed online with successful issuer authentication, the count 
begins anew, so that transactions may be processed offline until the lower limit is again 
reached. 


November 2011 Page 113 


10 Functions Used in Transaction Processing EMV 4.3 Book 3 
10.7 Terminal Action Analysis Application Specification 


10.7 Terminal Action Analysis 


Purpose: 


Once terminal risk management and application functions related to a normal 
offline transaction have been completed, the terminal makes the first decision as 
to whether the transaction should be approved offline, declined offline, or 
transmitted online. 


e Ifthe outcome of this decision process is to proceed offline, the terminal issues 
a GENERATE AC command to ask the ICC to return a TC. 


e Ifthe outcome of the decision is to go online, the terminal issues a 
GENERATE AC command to ask the ICC for an Authorisation Request 
Cryptogram (ARQC). 


e If the decision is to reject the transaction, the terminal issues a GENERATE 
AC to ask for an Application Authentication Cryptogram (AAC). 


An offline decision made here is not final. If the terminal asks for a TC from the 
ICC, the ICC, as a result of card risk management, may return an ARQC or AAC. 


Conditions of Execution: 
The terminal action analysis function is always performed. 
Sequence of Execution: 


The terminal action analysis function is performed after terminal risk 
management and cardholder and/or merchant transaction data entry has been 
completed. It shall be performed prior to the first use of the GENERATE AC 


command. 


The Issuer Action Code - Default and Terminal Action Code - Default processing 
described below shall also be performed after online processing is attempted in 
the case where the terminal was unable to process the transaction online. 


The terminal action analysis function may be executed at several places during a 
transaction to eliminate the need for unnecessary processing. If any processing 
results in the setting of a bit in the TVR (for example, failure of cardholder 
verification), it may be desirable to perform this function immediately to 
determine whether the transaction should be rejected offline based upon the 
issuer’s parameters in the ICC or the acquirer’s parameters in the terminal. 
Recognition of such a decision early in processing may allow the terminal to avoid 
prolonging a transaction that will ultimately be rejected. Multiple execution of 
this decision process is optional on the part of the terminal. 
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Description: 


The terminal shall make a preliminary decision to reject the transaction, 
complete it online, or complete it offline based upon the TVR, issuer action 
preferences, and acquirer action preferences according to the method described in 
this section. 


The ICC contains (optionally) three data elements to reflect the issuer’s selected 
action to be taken based upon the content of the TVR. Each of the three data 
elements has defaults specified here in case any of these data elements are 
absent from the ICC. The three data elements are: 


e Issuer Action Code - Denial 
e Issuer Action Code - Online 
e Issuer Action Code - Default 


Collectively, these three data objects are termed the Issuer Action Codes. The 
purpose of each is described in this section. The format of each is identical and 
mirrors the TVR. Each has one bit corresponding to each bit in the TVR, and the 
Issuer Action Code (IAC) bit specifies an action to be taken if the corresponding 
bit in the TVR is set to 1. Thus, the size and format of each of the Issuer Action 
Codes is identical to the TVR. 


Similarly, the terminal may contain three data elements to reflect the acquirer’s 
selected action to be taken based upon the content of the TVR. These data 
elements are: 


e Terminal Action Code - Denial 
e Terminal Action Code - Online 
e Terminal Action Code - Default 


Collectively, these three data objects are termed the Terminal Action Codes. The 
purpose of each is described in this section. The format of each is identical and 
mirrors the TVR. Each has one bit corresponding to each bit in the TVR, and the 
Terminal Action Code (TAC) bit specifies an action to be taken if the 
corresponding bit in the TVR is set to 1. Thus, the size and format of each of the 
Terminal Action Codes is identical to the TVR and to the Issuer Action Codes. 


The existence of each of the Terminal Action Codes is optional. In the absence of 
any Terminal Action Code, a default value consisting of all bits set to 0 is to be 
used in its place. However, it is strongly reeommended that as a minimum, the 
Terminal Action Code - Online and Terminal Action Code - Default should be 
included with the bits corresponding to ‘Offline data authentication was not 
performed’, and either ‘SDA failed’, or ‘DDA failed’ or ‘CDA failed’ set to 1.% 


15 This protects against a fraudulent card with all the bits in the Issuer Action Code set to 
0. Without this protection, such a card could be created with no possibility of going online 
or declining transactions. All transactions would be approved offline. 
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Processing of the action codes is done in pairs, that is, the Issuer Action Code - 
Denial is processed together with the Terminal Action Code - Denial, the Issuer 
Action Code - Online is processed together with the Terminal Action Code - 
Online, and the Issuer Action Code - Default is processed together with the 
Terminal Action Code - Default. Processing of the action codes shall be performed 
in the order specified here. 


If the Issuer Action Code - Denial does not exist, a default value with all bits set 
to 0 is to be used. Together, the Issuer Action Code - Denial and the Terminal 
Action Code - Denial specify the conditions that cause denial of a transaction 
without attempting to go online. If either data object exists, the terminal shall 
inspect each bit in the TVR. For each bit in the TVR that has a value of 1, the 
terminal shall check the corresponding bits in the Issuer Action Code - Denial 
and the Terminal Action Code - Denial. If the corresponding bit in either of the 
action codes is set to 1, it indicates that the issuer or the acquirer wishes the 
transaction to be rejected offline. In this case, the terminal shall issue a 
GENERATE AC command to request an AAC from the ICC. This AAC may be 
presented to the issuer to prove card presence during this transaction, but details 
of handling a rejected transaction are outside the scope of this specification. 


If the Issuer Action Code - Online is not present, a default value with all bits set 
to 1 shall be used in its place. Together, the Issuer Action Code - Online and the 
Terminal Action Code - Online specify the conditions that cause a transaction to 
be completed online. These data objects are meaningful only for terminals 
capable of online processing. Offline-only terminals may skip this test and 
proceed to checking the Issuer Action Code - Default and Terminal Action Code - 
Default, described below. For an online-only terminal, if it has not already 
decided to reject the transaction as described above, it shall continue transaction 
processing online, and shall issue a GENERATE AC command requesting an 
ARQC from the card. For a terminal capable of online processing, if the terminal 
has not already decided to reject the transaction as described above, the terminal 
shall inspect each bit in the TVR. For each bit in the TVR that has a value of 1, 
the terminal shall check the corresponding bits in both the Issuer Action Code - 
Online and the Terminal Action Code - Online. If the bit in either of the action 
codes is set to 1, the terminal shall complete transaction processing online and 
shall issue a GENERATE AC command requesting an ARQC from the ICC. 
Otherwise, the terminal shall issue a GENERATE AC command requesting a TC 
from the ICC. 
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If the Issuer Action Code - Default does not exist, a default value with all bits set 
to 1 shall be used in its place. Together, the Issuer Action Code - Default and the 
Terminal Action Code - Default specify the conditions that cause the transaction 
to be rejected if it might have been approved online but the terminal is for any 
reason unable to process the transaction online. The Issuer Action Code - Default 
and the Terminal Action Code - Default are used only if the Issuer Action Code - 
Online and the Terminal Action Code - Online were not used (for example, in 
case of an offline-only terminal) or indicated a desire on the part of the issuer or 
the acquirer to process the transaction online but the terminal was unable to go 
online. In the event that an online-only terminal was unable to successfully go 
online, it may optionally skip TAC/IAC Default processing (shown in Figure 7 for 
a transaction that was not completed on-line)!*. If an online-only terminal does 
skip TAC/IAC Default processing, it shall request an AAC with the second 
GENERATE AC command. If the terminal has not already rejected the 
transaction and the terminal is for any reason unable to process the transaction 
online, the terminal shall use this code to determine whether to approve or reject 
the transaction offline. If any bit in Issuer Action Code - Default or the Terminal 
Action Code - Default and the corresponding bit in the TVR are both set to 1, the 
transaction shall be rejected and the terminal shall request an AAC to complete 
processing. If no such condition appears, the transaction may be approved offline, 
and a GENERATE AC command shall be issued to the ICC requesting a TC. 


If CDA is to be performed (as described in section 10.3 of this book and section 
6.6 of Book 2), the terminal shall set the bit for ‘CDA Signature Requested’ in the 
GENERATE AC command to 1. 


16 Note that if an online-only terminal is unable to successfully go online and TAC/IAC 
Default processing is optionally performed, this could result in a TC being requested with 
the second GENERATE AC command (depending upon the TAC/IAC Default settings). 
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10.8 Card Action Analysis 


Purpose: 


An ICC may perform its own risk management to protect the issuer from fraud or 
excessive credit risk. Details of card risk management algorithms within the ICC 
are specific to the issuer and are outside the scope of this specification, but as a 
result of the risk management process, an ICC may decide to complete a 
transaction online or offline or reject the transaction. The ICC may also decide 
that an advice message should be sent to the issuer to inform the issuer of an 
exceptional condition. 


Conditions of Execution: 


The card online/offline decision is specified by its response to the GENERATE AC 
command. Therefore, this section applies to all transactions. Whether the ICC 
performs any risk management tests is transparent to the terminal and outside 
the scope of this specification. 


Sequence of Execution: 


The card action analysis process is performed when the terminal issues the 
GENERATE AC command for a given transaction. 


Description: 


The result of risk management performed by the ICC is a decision for one of the 
following actions to be taken by the terminal: 


e Approve the transaction offline. This option is available to the ICC only if the 
terminal has made a preliminary decision to complete the transaction offline, 
as described in section 10.7. 


e Complete the transaction online. 
e Reject the transaction. 


The decision by the ICC is made known to the terminal by returning a TC, an 
ARQC, or an AAC to the terminal in response to a GENERATE AC command, as 
described in section 6.5.5. 


Upon the completion of the card action analysis function, the terminal shall set 
the ‘Card risk management was performed’ bit in the TSI to 1. 
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10.8.1 Terminal Messages for an AAC 


An AAC returned by the card indicates either a rejection of the specific 
transaction or a restriction that disallows use of the card in the environment of 
the transaction (for example, the card application may be restricted only to 
specific merchant categories). In both cases, the card disapproves the transaction, 
but the terminal may choose to display different messages in the two cases. The 
card may optionally distinguish the cases by the use of the code returned in the 
Cryptogram Information Data (see the GENERATE AC command in 

section 6.5.5). If an AAC is returned with b8-b1 = '001' in the Cryptogram 
Information Data, the AAC was returned due to card restrictions. 


10.8.2 Advice Messages 


The issuer may wish for an advice message, separate from either an 
authorisation request or a clearing message, to be sent in certain exception cases. 
(Currently, the only identified such case is ‘PIN Try Limit exceeded’, but 
allowance has been made for the addition of other cases later; see Table 14). 


If b4 of the Cryptogram Information Data is 1, the terminal shall process the 
transaction as shown in Book 4, sections 6.3.7 and 12.2.5. Further information 
may be found in complementary payment system documentation. 
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10.9 Online Processing 


Purpose: 


Online processing is performed to ensure that the issuer can review and 
authorise or reject transactions that are outside acceptable limits of risk defined 
by the issuer, the payment system, or the acquirer. 


Conditions of Execution: 


Online processing shall be performed if the ICC returns an ARQC in response to 
the first GENERATE AC command for the transaction. 


Sequence of Execution: 


The online processing function is performed when the terminal receives an ARQC 
in response to the first GENERATE AC command. 


Description: 


In general, online processing is the same as online processing of magnetic stripe 
transactions and is not described here. This section is limited to the additional 
online processing provided in an ICC environment that is not available in a 
magnetic stripe environment. 


The ARQC may be sent in the authorisation request message.!7 The 
authorisation response message from the issuer may contain the Issuer 
Authentication Data (tag '91'). If the Issuer Authentication Data is received in 
the authorisation response message and the Application Interchange Profile 
indicates that the ICC supports issuer authentication, the Issuer Authentication 
Data shall be sent to the ICC in the EXTERNAL AUTHENTICATE command. If 
the ICC responds with SW1 SW2 other than '9000'", the terminal shall set the 
‘Issuer authentication failed’ bit in the TVR to 1. 


17 Actions performed by the acquirer or issuer systems are outside the scope of this 
specification. However, an explanation of what is expected to take place at the issuer may 
be useful for clarity. The ARQC is a cryptogram generated by the card from transaction 
data using an issuer key stored in the card and known at the issuer authorisation system. 
The issuer uses this key to authenticate the ARQC and thereby authenticate the card. 
This process is termed ‘online card authentication’ or simply ‘card authentication’. 


Subsequent to card authentication, the issuer may generate a cryptogram on selected 
data included in the authorisation response or already known to the card. This 
cryptogram is sent to the terminal in the authorisation response as part of the Issuer 
Authentication Data. The terminal provides the Issuer Authentication Data to the ICC in 
the EXTERNAL AUTHENTICATE command or the second GENERATE AC command, 
as described in Part I. The ICC may use the Issuer Authentication Data to authenticate 
that the response message originated from the issuer. 
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If the Issuer Authentication Data is received but the Application Interchange 
Profile indicates that the ICC does not support issuer authentication, this 
indicates that the ICC has combined the issuer authentication function with the 
GENERATE AC command. In this case, or if no Issuer Authentication Data is 
received, the terminal shall not execute the EXTERNAL AUTHENTICATE 


command. 


The ICC shall permit at most one EXTERNAL AUTHENTICATE command in a 
transaction. If the terminal issues more than one, the second and all succeeding 
EXTERNAL AUTHENTICATE commands shall end with SW1 SW2 = '6985'. 


Upon completion of online processing, if the EXTERNAL AUTHENTICATE 
command was sent to the card by the terminal, the terminal shall set the ‘Issuer 
authentication was performed’ bit in the TSI to 1. 


Note: Annex F provides additional information about status words to be returned in 
response to an EXTERNAL AUTHENTICATE command. 
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10.10 Issuer-to-Card Script Processing 


Purpose: 


An issuer may provide command scripts to be delivered to the ICC by the 
terminal to perform functions that are not necessarily relevant to the current 
transaction but are important for the continued functioning of the application in 
the ICC. Multiple scripts may be provided with an authorisation response, and 
each may contain any number of Issuer Script Commands. Script processing is 
provided to allow for functions that are outside the scope of this specification but 
are nonetheless necessary. !8 


A script may contain Issuer Script Commands not known to the terminal, but the 
terminal shall deliver each command to the ICC individually according to this 
specification. 


Conditions of Execution: 
None. 
Sequence of Execution: 


Two separate script tags are available for use by the issuer. Issuer scripts with 
tag '71' shall be processed prior to issuing the final GENERATE AC command. 
Issuer scripts with tag '72' shall be processed after issuing the final 
GENERATE AC command. 


18 An example might be unblocking of an offline PIN, which might be done differently by 
various issuers or payment systems. 
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Description: 


An Issuer Script is a constructed data object (tag '71' or '72') containing 
(optionally) a Script Identifier and a sequence of Issuer Script Command APDUs 
to be delivered serially to the ICC. The Script Identifier is optional and is not 
interpreted by the terminal; it is meaningful only to the issuer. Figure 14 and 
Figure 15 illustrate an Issuer Script containing a Script Identifier and three 
commands. 


— or — including Script | '9F18' | '04' | Identifier | (see Figure 15) 
"72! ID, tags, and lengths) (4 bytes) 


Figure 14: Issuer Script Format 


Tes [EoD [Command [a [LaV) [Command [66 [Hv [ Command 


Figure 15: Issuer Script Command Format (Shown with Three Commands) 


It is possible for multiple Issuer Scripts to be delivered with a single 
authorisation response. The terminal shall process each Issuer Script in the 
sequence in which it appears in the authorisation response according to the 
following rules: 


e Issuer Script Commands shall be separated using the BER-TLV coding of the 
data objects defining the commands (tag '86'). 


e Each command shall be delivered to the ICC as a command APDU in the 
sequence in which it appeared in the Issuer Script. 


e The terminal shall examine only SW1 in the response APDU and perform one 
of the following actions: 


« If SW1 indicates either normal processing or a ‘warning’ according to the 
conventions described in this specification, the terminal shall continue 
with the next command from the Issuer Script (if any). 


« If SW1 indicates an ‘error’ condition, the processing of the Issuer Script 
shall be terminated. 


If an Issuer Script is processed, the terminal shall set the ‘Script processing was 
performed’ bit in the TSI to 1. If an error occurred in processing a script, the 
terminal shall set to 1 either the ‘Script processing failed before final 
GENERATE AC’ in the TVR if the identifying tag of the failing script was '71' or 
the ‘Script processing failed after final GENERATE AC’ in the TVR if the tag 
was '72'. 


Note: Annex E discusses TVR and TSI bit settings following script processing. 
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10.11 Completion 


Purpose: 
The completion function closes processing of a transaction. 
Conditions of Execution: 


The terminal always performs this function unless the transaction is terminated 
prematurely by error processing. 


Sequence of Execution: 


The completion function is always the last function in the transaction processing. 
(Script processing may be performed after the completion function.) 


Description: 


The ICC indicates willingness to complete transaction processing by returning 
either a TC or an AAC to either the first or second GENERATE AC command 
issued by the terminal. If the terminal decides to go online, completion shall be 
done when the second GENERATE AC command is issued. 


If the terminal is to perform CDA (as described in section 10.3), the terminal 
shall set the ‘CDA signature requested’ bit in the GENERATE AC command to 1. 


See section 9 for additional information on the use of the GENERATE AC 
command. 
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Annex A Data Elements Dictionary 
Table 33 defines those data elements that may be used for financial transaction interchange and their mapping onto data 


objects and files. Table 34 lists the data elements in tag sequence. 


The characters used in the “Format” column are described in section 4.3, Data Element Format Convention. 


A1 Data Elements by Name 


a ca 
Account Type Indicates the type of account selected on the Terminal ‘SF57 
terminal, coded as specified in Annex G 
Acquirer Uniquely identifies the acquirer within each Terminal n6-11 'QFO1' 
Identifier payment system 


Additional Indicates the data input and output Terminal '9F40' 5 
Terminal capabilities of the terminal 

Capabilities 

Amount, Authorised amount of the transaction Terminal '81' 4 
Authorised (excluding adjustments) 

(Binary) 


Table 33: Data Elements Dictionary 
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el 


Amount, Authorised amount of the transaction Terminal 'OF02' 
Authorised (excluding adjustments) 

(Numeric) 

Amount, Other Secondary amount associated with the Terminal '9FO4' 
(Binary) transaction representing a cashback amount 

Amount, Other Secondary amount associated with the Terminal 

(Numeric) transaction representing a cashback amount 


Amount, Authorised amount expressed in the reference Terminal 'OF3A' 4 
Reference currency 
Currency 


Application Cryptogram returned by the ICC in response of '77' or '80' | '9F26' 
Cryptogram the GENERATE AC command 


Application Indicates the currency in which the account is '70' or '77' | '9F42' 
Currency Code managed according to ISO 4217 


Application Indicates the implied position of the decimal '70' or '77' | '9F44' 1 
Currency point from the right of the amount represented 

Exponent according to ISO 4217 

Application Issuer or payment system specified data '70' or '77' | '9FO5' 1-32 
Discretionary relating to the application 

Data 

Application Date from which the application may be used ICC n6 '70' or '77' | '5F25' 3 
Effective Date YYMMDD 


Table 33: Data Elements Dictionary, continued 


November 2011 Page 128 


EMV 4.3 Book 3 Annex A_ Data Elements Dictionary 
Application Specification Al Data Elements by Name 


a Oe i 


Application Date after which application expires n6 '70' or '77' | '5F24' 
Expiration Date YYMMDD 
Application File | Indicates the location (SFI, range of records) of '77' or '80' '94' var. Eo 
Locator (AFL) the AEFs related to a given application to Eo 
Application Identifies the application as described in ‘61' '4F" 5-16 | 
Dedicated File ISO/IEC 7816-5 
(ADF) Name 

Application Identifies the application as described in Terminal 

Identifier (AID) — | ISO/IEC 7816-5 

terminal 


Application Indicates the capabilities of the card to support 'T77' or '80' 
Interchange specific functions in the application 


Profile 


Application Preferred mnemonic associated with the AID 
Preferred Name 


ans (see '61' or 'A5' 
section 
4.3) 


Application Valid cardholder account number '70' or '77' 
Primary Account 


Number (PAN) 


Application Mnemonic associated with the AID according ans with | '61' or 'A5' 
Label to ISO/IEC 7816-5 the special 
character 
limited to 
space 


Table 33: Data Elements Dictionary, continued 
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ee 


Application Identifies and differentiates cards with the '70' or '77' 
Primary Account | same PAN 

Number (PAN) 

Sequence 

Number 


Application Indicates the priority of a given application or '61' or 'A5' 
Priority group of applications in a directory 
Indicator 


Currency Code; each code is 3 digits according 
to ISO 4217 


Application Indicates the implied position of the decimal '70' or '77' | '9F43' 
Reference point from the right of the amount, for each of 


Application 1-4 currency codes used between the terminal '70' or '77' | '9F3B' 
Reference and the ICC when the Transaction Currency 
Currency Code is different from the Application 


Currency the 1-4 reference currencies represented 
Exponent according to ISO 4217 


Table 33: Data Elements Dictionary, continued 
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[Name [Description | Source | Format | Template [ Tag | Lenath | 


Application 
Selection 
Indicator 


Application 
Template 


Application 
Transaction 
Counter (ATC) 


Application 
Usage Control 


Application 
Version Number 


Application 
Version Number 


At the 
discretion 
of the 
terminal. 
The data 
is not sent 
across the 
interface 


For an application in the ICC to be supported Terminal 
by an application in the terminal, the 

Application Selection Indicator indicates 

whether the associated AID in the terminal 

must match the AID in the card exactly, 

including the length of the AID, or only up to 


the length of the AID in the terminal 


There is only one Application Selection 
Indicator per AID supported by the terminal 


Contains one or more data objects relevant to 
an application directory entry according to 
ISO/IEC 7816-5 


Counter maintained by the application in the 'T7' or '80' 
ICC (incrementing the ATC is managed by the 


ICC) 
Indicates issuer’s specified restrictions on the MO Or EL 
geographic usage and services allowed for the 


ICC 
| 

ICC 

application 

Version number assigned by the payment ICC 

system for the application 

Version number assigned by the payment Terminal 

system for the application 


Table 33: Data Elements Dictionary, continued 


'70' or '77' 


var. up 
to 252 


— 
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[Name [Description | Source | Format | Template [ Tag | Lenath | 


Authorisation Value generated by the authorisation authority As defined 

Code for an approved transaction by the 
Payment 
Systems 


Authorisation Code that defines the disposition of a message Issuer/ 
Response Code Terminal 


Authorisation Cryptogram generated by the issuer and used Issuer 4 or 8 
Response by the card to verify that the response came 

Cryptogram from the issuer. 

(ARPC) 


Bank Identifier Uniquely identifies a bank as defined in ISO "BFOC' or | '5F54' | 8or11 
Code (BIC) 9362. "73 

Card Risk List of data objects (tag and length) to be "10" or TT '8C' var. up 
Management passed to the ICC in the first GENERATE AC to 252 
Data Object command 

List 1 (CDOL1) 

Card Risk List of data objects (tag and length) to be '70' or '77' var. up 
Management passed to the ICC in the second GENERATE to 252 
Data Object AC command 

List 2 (CDOL2) 


Table 33: Data Elements Dictionary, continued 
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[ne Tessin Taree rennet [rent [tegen 


Card Status Contains data sent to the ICC to indicate Issuer 
Update (CSU) whether the issuer approves or declines the 
transaction, and to initiate actions specified by 
the issuer. Transmitted to the card in Issuer 
Authentication Data. 


Cardholder Indicates cardholder name according to ans 2-26 '70' or '77' | '5F20' - 
Name ISO 7813 
Cardholder Indicates the whole cardholder name when ans 27-45 | '70'or'77' | '9FOB' 27-45 
Name Extended | greater than 26 characters using the same 

coding convention as in ISO 7813 


Cardholder Identifies a method of verification of the '70' or '77' 'SE' 10-252 
Verification cardholder supported by the application 

Method (CVM) 

List 


Cardholder Indicates the results of the last CVM Terminal 
Verification performed 

Method (CVM) 

Results 


Certification A check value calculated on the concatenation Terminal 
Authority Public | of all parts of the Certification Authority 
Key Check Sum _|} Public Key (RID, Certification Authority Public 

Key Index, Certification Authority Public Key 

Modulus, Certification Authority Public Key 

Exponent) using SHA-1 
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Certification Value of the exponent part of the Certification | Terminal lor3 
Authority Public | Authority Public Key 
Key Exponent 


Certification Identifies the certification authority's public '70' or '77' 
Authority Public | key in conjunction with the RID 
Key Index 


Certification Identifies the certification authority's public Terminal 'QF22' 1 
Authority Public | key in conjunction with the RID 

Key Index 

Certification Value of the modulus part of the Certification Terminal NCA 
Authority Public | Authority Public Key (up to 
Key Modulus 248) 


Command Identifies the data field of a command message | Terminal '83' var. 
Template 

Cryptogram Indicates the type of cryptogram and the ICC '77' or '80' | '9F27' 1 
Information actions to be performed by the terminal 

Data 

Data An issuer assigned value that is retained by ICC '9F45' 2 
Authentication the terminal during the verification process of 

Code the Signed Static Application Data 

Dedicated File Identifies the name of the DF as described in ICC '6F" '84' 5-16 
(DF) Name ISO/IEC 7816-4 
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Default Dynamic | DDOL to be used for constructing the Terminal var. 
Data INTERNAL AUTHENTICATE command if the 

Authentication DDOL in the card is not present 

Data Object List 

(DDOL) 

Default TDOL to be used for generating the TC Hash Terminal 

Transaction Value if the TDOL in the card is not present 

Certificate Data 

Object List 

(TDOL) 


Directory Identifies the name of a DF associated with a 

Definition File directory 

(DDF) Name 

Directory Issuer discretionary part of the directory "73! var. up 
Discretionary according to ISO/IEC 7816-5 to 252 
Template 


Dynamic Data List of data objects (tag and length) to be '70' or '77' 
Authentication passed to the ICC in the INTERNAL 

Data Object List | AUTHENTICATE command 

(DDOL) 


Enciphered Transaction PIN enciphered at the PIN pad for | Terminal 
Personal online verification or for offline verification if 
Identification the PIN pad and IFD are not a single 


Number (PIN) integrated device 
Data 
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File Control Issuer discretionary part of the FCI 'AS' "BFOC' | var. up 
Information to 222 
(FCI) Issuer 

Discretionary 

Data 

File Control Identifies the data object proprietary to this r. '6F" 'AS' Yr: 
Information specification in the FCI template according to 

(FCI) ISO/IEC 7816-4 

Proprietary 

Template 


File Control Identifies the FCI template according to ICC var. '6F' var. up 
Information ISO/IEC 7816-4 to 252 
(FCI) Template 

ICC Dynamic Time-variant number generated by the ICC, to ICC '9F4C' 2-8 
Number be captured by the terminal 


Integrated ICC PIN Encipherment Public Key certified by ICC '70' or '77' | '9F2D' NI 
Circuit Card the issuer 

(ICC) PIN 

Encipherment 

Public Key 

Certificate 
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Integrated ICC PIN Encipherment Public Key Exponent ICC '70' or '77' | '9F2E' lor3 
Circuit Card used for PIN encipherment 
(ICC) PIN 
Encipherment 
Public Key 
Exponent 
ICC b 


Integrated Remaining digits of the ICC PIN '70' or '77' | '9F2F' | NPR - 
Circuit Card Encipherment Public Key Modulus NI + 42 
(ICC) PIN 

Encipherment 

Public Key 

Remainder 


Integrated ICC Public Key certified by the issuer '70' or '77' | '9F46' 
Circuit Card 

(ICC) Public Key 

Certificate 


Integrated ICC Public Key Exponent used for the '70' or '77' 
Circuit Card verification of the Signed Dynamic Application 


(ICC) Public Key | Data 
Exponent 


Integrated Remaining digits of the ICC Public Key '70' or '77' 
Circuit Card Modulus 

(ICC) Public Key 

Remainder 
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Interface Device 
(FD) Serial 
Number 


International 
Bank Account 
Number (IBAN) 


Issuer Action 
Code - Default 


Issuer Action 
Code - Denial 


Issuer Action 
Code - Online 


Issuer 
Application Data 


Unique and permanent serial number assigned | Terminal 


to the IFD by the manufacturer 


Uniquely identifies the account of a customer 
at a financial institution as defined in ISO 
13616. 


Specifies the issuer’s conditions that cause a 
transaction to be rejected if it might have been 
approved online, but the terminal is unable to 
process the transaction online 


Specifies the issuer’s conditions that cause the 
denial of a transaction without attempt to go 
online 


Specifies the issuer’s conditions that cause a 
transaction to be transmitted online 


Contains proprietary application data for 
transmission to the issuer in an online 
transaction. 


Note: For CCD-compliant applications, Annex C, 
section C7 defines the specific coding of the Issuer 
Application Data (IAD). To avoid potential conflicts 
with CCD-compliant applications, it is strongly 
recommended that the IAD data element in an 
application that is not CCD-compliant should not 
use the coding for a CCD-compliant application 


a _ _ 


"BFOC' or | '5F53' 
173! 


'70' or '77' 
'70' or '77' 


10) Ore TE 


'77' or '80' 
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Issuer Data sent to the ICC for online issuer 
Authentication authentication 
Data 


Issuer Code Indicates the code table according to 'OF11' 
Table Index ISO/IEC 8859 for displaying the Application 
Preferred Name 


Issuer Country Indicates the country of the issuer according to '70' or '77' | '5F28' 
Code ISO 3166 


Issuer Country Indicates the country of the issuer as defined 
Code (alpha2 in ISO 3166 (using a 2 character alphabetic 
format) code) 


Issuer Country Indicates the country of the issuer as defined 
Code (alpha3 in ISO 3166 (using a 3 character alphabetic 
format) code) 


Issuer The number that identifies the major industry 
Identification and the card issuer and that forms the first 
Number (IIN) part of the Primary Account Number (PAN) 


Issuer Public Issuer public key certified by a certification ICC '70' or '77' NCA 
Key Certificate authority 
Issuer Public Issuer public key exponent used for the ICC 0! or*TT | *9R32' 1to3 
Key Exponent verification of the Signed Static Application 

Data and the ICC Public Key Certificate 
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Issuer Public Remaining digits of the Issuer Public Key ICC '70' or '77' "92' NI - 
Key Remainder | Modulus Ne if 
Issuer Script Contains a command for transmission to the Issuer "71' or '72' var. up 
Command ICC to 261 
Issuer Script Identification of the Issuer Script Issuer ‘T1' or '72' | '9F18' 4 
Identifier 

Issuer Script Indicates the result of the terminal script Terminal var. 
Results processing 


Issuer Script Contains proprietary issuer data for Issuer wal var. 
Template 1 transmission to the ICC before the second 
GENERATE AC command 


Issuer Script Contains proprietary issuer data for Issuer "72! var. 
Template 2 transmission to the ICC after the second 

GENERATE AC command 
Issuer URL The URL provides the location of the Issuer’s ICC ans "BFOC' or | '5F50' 

Library Server on the Internet. "73! 


Language 1-4 languages stored in order of preference, ICC an 2 "A5' 
Preference each represented by 2 alphabetical characters 

according to ISO 639 

Note: EMVCo strongly recommends that cards be 

personalised with data element '5F2D' coded in 

lowercase, but that terminals accept the data 

element whether it is coded in upper or lower case. 
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[Name SSS~C« ipo 


Last Online 
Application 
Transaction 
Counter (ATC) 
Register 


Log Entry Provides the SFI of the Transaction Log file 
and its number of records "73! 


Log Format 


Lower 
Consecutive 
Offline Limit 


Maximum 
Target 
Percentage to be 
used for Biased 
Random 
Selection 


Merchant 
Category Code 


[Source | Format | Template | Tag | Length 


a - - 


'BFOC’ or | '9F4D' a 
passed to the terminal when a transaction log 


ICC 'OF4F" var. 
record is read 
Issuer-specified preference for the maximum ICC '70' or '77' | '9F14' 1 
number of consecutive offline transactions for 
this ICC application allowed in a terminal with 
online capability 


Value used in terminal risk management for Terminal 
random transaction selection 
ahi - 


Table 33: Data Elements Dictionary, continued 


ATC value of the last transaction that went 
online 


List (in tag and length format) of data objects 
representing the logged data elements that are 


Classifies the type of business being done by 
the merchant, represented according to 

ISO 8583:1993 for Card Acceptor Business 
Code 
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[Name [S~Cesription 

Merchant When concatenated with the Acquirer Terminal ans 15 ‘OF 16' 

Identifier Identifier, uniquely identifies a given merchant 

Merchant Name _| Indicates the name and location of the Terminal 'OF4E' r. 

and Location merchant 

Message Type Indicates whether the batch data capture Terminal n2 1 
record is a financial record or advice 


_ SEE 


Personal 
Identification 
Number (PIN) 
Pad Secret Key 


Personal 
Identification 
Number (PIN) 
Try Counter 


Point-of-Service 
(POS) Entry 
Mode 


Processing 
Options Data 
Object List 
(PDOL) 


Proprietary 
Authentication 
Data 


Secret key of a symmetric algorithm used by 
the PIN pad to encipher the PIN and by the 
card reader to decipher the PIN if the PIN pad 
and card reader are not integrated 


Number of PIN tries remaining 


Indicates the method by which the PAN was Terminal 
entered, according to the first two digits of the 
ISO 8583:1987 POS Entry Mode 


Contains a list of terminal resident data 
objects (tags and lengths) needed by the ICC in 
processing the GET PROCESSING OPTIONS 


command 


Contains issuer data for transmission to the Issuer 
card in the Issuer Authentication Data of an 


online transaction. 
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a OC i 


READ RECORD | Contains the contents of the record read. '70' var. up 
Response (Mandatory for SFIs 1-10. Response messages to 252 
Message for SFIs 11-30 are outside the scope of EMV, 

Template but may use template '70') 

Response Contains the data objects (without tags and r. r. 
Message lengths) returned by the ICC in response to a 

Template command 

Format 1 


Response Contains the data objects (with tags and ICC var. ari a var. 
Message lengths) returned by the ICC in response to a 

Template command 

Format 2 


Service Code Service code as defined in ISO/IEC 7813 for '70' or '77' '5F30' 
track 1 and track 2 


Short File Identifies the AEF referenced in commands 

Identifier (SFI related to a given ADF or DDF. It is a binary 
data object having a value in the range 1 to 30 
and with the three high order bits set to zero. 


Signed Dynamic | Digital signature on critical application ICC '77' or '80' | '9F4B' NIC | 
Application Data | parameters for DDA or CDA 

Signed Static Digital signature on critical application ICC '70' or '77' '93' NI 
Application Data | parameters for SDA 
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Static Data List of tags of primitive data objects defined in ICC '70' or '77' | '9F4A' var. 
Authentication this specification whose value fields are to be 
Tag List included in the Signed Static or Dynamic 
Application Data 
Target Value used in terminal risk management for Terminal 
Percentage to be | random transaction selection 
Used for Random 
Selection 
Terminal Action | Specifies the acquirer’s conditions that cause a | Terminal 5 
Code - Default transaction to be rejected if it might have been 
approved online, but the terminal is unable to 
process the transaction online 


Terminal Action | Specifies the acquirer’s conditions that cause Terminal 5 
Code - Denial the denial of a transaction without attempt to 

go online 
Terminal Action | Specifies the acquirer’s conditions that cause a | Terminal 5 
Code - Online transaction to be transmitted online 
Terminal Indicates the card data input, CVM, and Terminal '9F33' 3 
Capabilities security capabilities of the terminal 
Terminal Indicates the country of the terminal, Terminal n3 'OF1A' 2 
Country Code represented according to ISO 3166 
Terminal Floor Indicates the floor limit in the terminal in Terminal ‘OF 1B' 4 
Limit conjunction with the AID 
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Terminal Designates the unique location of a terminal at | Terminal an 8 '9F1C' 
Identification a merchant 


Terminal Risk 
Management 
Data 


Terminal Type 


Terminal 
Verification 
Results 


Threshold Value 
for Biased 
Random 
Selection 


Track 1 
Discretionary 
Data 


Track 2 
Discretionary 
Data 


Application-specific value used by the card for | Terminal 'OF1D' 
risk management purposes 

Indicates the environment of the terminal, its Terminal 'OF35' 
communications capability, and its operational 

control 

Status of the different functions as seen from Terminal '95' 
the terminal 


Discretionary part of track 1 according to 
ISO/IEC 7813 


'70' or '77' | 'OF LE" 
'70' or '77' | '9F20' 


ISO/IEC 78138 


Value used in terminal risk management for Terminal 
random transaction selection 
‘ fal 


Discretionary part of track 2 according to 
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a OC 


Track 2 
Equivalent Data 


Transaction 
Amount 


Transaction 
Certificate Data 
Object List 
(TDOL) 


Transaction 
Certificate (TC) 
Hash Value 


Contains the data elements of track 2 '70' or '77' 
according to ISO/IEC 7818, excluding start 
sentinel, end sentinel, and Longitudinal 
Redundancy Check (LRC), as follows: 


Primary Account Number 


Field Separator (Hex 'D') 
Expiration Date (YYMM) 
Service Code 


Discretionary Data (defined by individual 
payment systems) 


Pad with one Hex 'F" if needed to ensure 
whole bytes 


Clearing amount of the transaction, including Terminal n12 

tips and other adjustments 

List of data objects (tag and length) to be used ICC '70' or '77' '97' var. up 
by the terminal in generating the TC Hash to 252 
Value 

Result of a hash function specified in Book 2, Terminal 20 
Annex B3.1 
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Transaction Indicates the currency code of the transaction Terminal 'BF2A' 
Currency Code according to ISO 4217 


Transaction 
Currency 
Exponent 


Indicates the implied position of the decimal Terminal '5F36' 
point from the right of the transaction amount 
represented according to ISO 4217 


Transaction Date | Local date that the transaction was authorised | Terminal 


Transaction 
Personal 
Identification 
Number (PIN) 


Data 


Transaction 
Reference 
Currency Code 


Transaction 
Reference 
Currency 
Conversion 


Transaction 
Reference 
Currency 
Exponent 


Data entered by the cardholder for the purpose | Terminal 
of the PIN verification 


Code defining the common currency used by Terminal 
the terminal in case the Transaction Currency 

Code is different from the Application 

Currency Code 


Factor used in the conversion from the Terminal 
Transaction Currency Code to the Transaction 
Reference Currency Code 


Indicates the implied position of the decimal Terminal 
point from the right of the transaction amount, 
with the Transaction Reference Currency Code 


represented according to ISO 4217 
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Transaction Counter maintained by the terminal that is Terminal 'OF41' 2-4 
Sequence incremented by one for each transaction 
Counter 


Transaction Indicates the functions performed in a Terminal 
Status transaction 
Information 


Transaction Local time that the transaction was authorised | Terminal n6 'QF21' 3 
Time HHMMSS 


Transaction Indicates the type of financial transaction, Terminal n2 '9C' 1 
Type represented by the first two digits of the 

ISO 8583:1987 Processing Code. The actual 

values to be used for the Transaction Type 

data element are defined by the relevant 

payment system 


Unpredictable Value to provide variability and uniqueness to | Terminal '9F37' 4 
Number the generation of a cryptogram 


Upper Issuer-specified preference for the maximum ICC '70' or '77' | '9F23' 1 
Consecutive number of consecutive offline transactions for 
Offline Limit this ICC application allowed in a terminal 

without online capability 
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When the length defined for the data object is greater than the length of the actual data, the following rules apply: 
e A data element in format n is right justified and padded with leading hexadecimal zeroes. 

e A data element in format cn is left justified and padded with trailing hexadecimal 'F's. 

e A data element in format a, an, or ans is left justified and padded with trailing hexadecimal zeroes. 


When data is moved from one entity to another (for example, card to terminal), it shall always be passed in order from high 
order to low order, regardless of how it is internally stored. The same rule applies when concatenating data. 


Note: Data that can occur in template '70' or '77' can never occur in both. 
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A2 Data Elements by Tag 


[ame Template [Tag 
[teaaction Cureeney Gade ———SSSCSC*dCSSC = 


Sequence Number 

[Traeaction Careney Egonent’ 
laccomt Typed 
ile Control Tnfomation OH Tonpate i 


Table 34: Data Elements Tags 


Page 150 November 2011 


EMV 4.3 Book 3 Annex A_ Data Elements Dictionary 
Application Specification A2 Data Elements by Tag 


[Name —SSSS~*dSCemptate [Tag] 
[READ RECORD Response MessageTongite |__| 0" 
ane Sere Templates 
anus Seript Template? —————SSS*CS id 
[Response Menage Template Format? =| «dia 
[Response Message Temlate Formats |__| a 
[acon thoveed ina) dar 
[command empiate ————SSSSCSC~sCSCSS*dC 
[Authorisation Goto ————SSSSSCSC~sdCSCS id 
[authviaton Rwpouae Gade SiS —*d 
amr Authentication Data dr 
[Terminal Verifaton Rewste Si Sd 
[Brasaction Centfinte (10 Hash Vane || om 


Transaction Personal Identification Number (PIN) ae hae 
Data 
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[Name SS*demptate [Tag _| 
Ee 
[Beanacton Status Taformation ~*~ 
aeaeaction toe ————SSSCSC*dCS id 
[Diretory Deion Fie DDH) Name ————~«Y ara 
Ee 
[Amount Authoreed Women) = —d 
[Amount Other Wumeriy ———————SS*S—d 
[Amount Other ine) ——————SSS* SC —*d 
[Applicaton Kentifer (AD) temminat «| __—__| Foe 
Appietion Version Number ~*~ 


Last Online Application Transaction Counter (ATC) '9F13' 
Register 


Ea 
Ee 
[Personal Teniiation Number PN) Try Counter [|_| 7 
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[Name SSS—*dCemptate [Tag] 
[Bernina Gomntsyole———SSSSCSCS~sCSSC =i 
[terminal For Lime —————SSCS—~sdCSS—*d 
[Terminal Taentintion ————SSCS—~sdCSCSCS*id 
[Meinl Risk Menagement Data ~~~ 
atte Deve FD) Serial Number =| —id 
[transaction ine SSCSC*CSSC*d 
ceriition Author Public Kay Tndax ~~ ae 
[terminal Capaibties ——————SSCSC~sdCSSC~*dt 
cartier Verein Mathod (GVA Rewate |__| aa 
[terminal Type SiS —*d 
[Wortitble Number 
Ponto Service (POS Bot Mode =| —id 
[amount Reference Currency id 
[teaneaction Reference Comreney Galo ——( aa 
[transaction Raerence Conreney Bxpnent |__| ora 
[Aditons\ Terminal Capabilities =| —+d ao 
[teaneaction Sequence Counter Sd 
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[Name S*dTemptate [Tag _| 
[Data Authentication Cote ——SCS—~sdCSCSS*d 


Dynamic Data Authentication Data Object List '70' or '77' '9F49' 
(DDOL) 


[CC RveamicNumber ————SSCSC*dCSSC id 
ercaot Nemeandaation ————SSC*sdSCSC =i 
a 


File Control Information (FCI) Issuer Discretionary 'BFOC' 
Data 


Table 34: Data Elements Tags, continued 


Page 154 November 2011 


EMV 4.3 Book 3 
Application Specification 


Annex B Rules for BER-TLV Data Objects 


As defined in ISO/IEC 8825, a BER-TLV data object consists of 2-3 consecutive 
fields: 


The tag field (T) consists of one or more consecutive bytes. It indicates a class, 
a type, and a number (see Table 35). The tag field of the data objects 
described in this specification is coded on one or two bytes. 


The length field (L) consists of one or more consecutive bytes. It indicates the 
length of the following field. The length field of the data objects described in 
this specification which are transmitted over the card-terminal interface is 
coded on one or two bytes. 


Note: Three length bytes may be used if needed for templates '71' and '72' and tag 
'86' (to express length greater than 255 bytes), as they are not transmitted over the 
card-terminal interface. 


The value field (V) indicates the value of the data object. If L ='00'", the value 
field is not present. 


A BER-TLV data object belongs to one of the following two categories: 


A primitive data object where the value field contains a data element for 
financial transaction interchange. 


A constructed data object where the value field contains one or more primitive 
or constructed data objects. The value field of a constructed data object is 
called a template. 


The coding of BER-TLV data objects is defined as follows. 
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B1 Coding of the Tag Field of BER-TLV Data 
Objects 


Table 35 describes the first byte of the tag field of a BER-TLV data object: 


See subsequent bytes 


Table 35: Tag Field Structure (First Byte) BER-TLV 


According to ISO/IEC 8825, Table 36 defines the coding rules of the subsequent 
bytes of a BER-TLV tag when tag numbers > 31 are used (that is, bits b5 - b1 of 
the first byte equal '11111'). 


}bs | b4[b3 | b2]b1 | Meaning 


Last tag byte 
Any value > 0 (Part of) tag number 


Table 36: Tag Field Structure (Subsequent Bytes) BER-TLV 


| Before, between, or after TLV-coded data objects, '00' bytes without any meaning 
may occur (for example, due to erased or modified TLV-coded data objects). 


Note: It is strongly recommended that issuers do not use tags beginning with ‘FF’ for 
proprietary purposes, as existing terminals may not recognise ‘FF’ as the beginning of a 
constructed private class tag. 
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The tag field of a BER-TLV data object is coded according to the following rules: 


e The following application class templates defined in ISO/IEC 7816 apply: 
'61' and '6F". 

e The following range of application class templates is defined in Part II: '70' to 
'TF'. The meaning is then specific to the context of an application according to 
this specification. Tags '78', '79', '7D', and '7E' are defined in ISO/IEC 7816-6 
and are not used in this specification. 


e The application class data objects defined in ISO/IEC 7816 and described in 
Part II are used according to the ISO/IEC 7816 definition. 


e Context-specific class data objects are defined in the context of this 
specification or in the context of the template in which they appear. 


e The coding of primitive context-specific class data objects in the ranges '80' to 
'9E' and '9F00' to '9F4F" is reserved for this specification. 


e The coding of primitive context-specific class data objects in the range '9F50' 
to '9F7F' is reserved for the payment systems. 


e The coding of tag 'BFOC' and constructed context-specific class data objects in 
the range 'BF20' to 'BF4F' is reserved for this specification. 


e The coding of constructed context-specific class data objects in the ranges 
'BF10' to 'BF1F' and 'BF50' to 'BF6F' is reserved for the payment systems. 


e The coding of constructed context-specific class data objects in the ranges 
'BFO1' to 'BFOB', 'BFOD' to 'BFOF’, and 'BF70' to 'BF7F' is left to the 
discretion of the issuer. 


e The coding of primitive and constructed private class data objects is left to the 
discretion of the issuer. 


B2 Coding of the Length Field of BER-TLV Data 
Objects 


When bit b8 of the most significant byte of the length field is set to 0, the length 
field consists of only one byte. Bits b7 to b1 code the number of bytes of the value 
field. The length field is within the range 1 to 127. 


When bit b8 of the most significant byte of the length field is set to 1, the 
subsequent bits b7 to b1 of the most significant byte code the number of 
subsequent bytes in the length field. The subsequent bytes code an integer 
representing the number of bytes in the value field. Two bytes are necessary to 
express up to 255 bytes in the value field. 
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B3 Coding of the Value Field of Data Objects 


A data element is the value field (V) of a primitive BER-TLV data object. A data 
element is the smallest data field that receives an identifier (a tag). 


A primitive data object is structured as illustrated in Figure 16: 


Figure 16: Primitive BER-TLV Data Object (Data Element) 


A constructed BER-TLV data object consists of a tag, a length, and a value field 
composed of one or more BER-TLV data objects. A record in an AEF governed by 
this specification is a constructed BER-TLV data object. A constructed data object 
is structured as illustrated in Figure 17: 


Length | Primitive or constructed Primitive or constructed 


BER-TLV data object BER-TLV data object 
number 1 number n 


Figure 17: Constructed BER-TLV Data Object 
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Annex C Coding of Data Elements Used in 
Transaction Processing 


This annex provides the coding for dynamic card data elements and specific data 
elements used to control the transaction flow in the terminal or to record the 
status of processing for the transaction. In the tables: 


e A‘l’ means that if that bit has the value 1, the corresponding ‘Meaning’ 
applies. 


e An‘x’ means that the bit does not apply. 
Data (bytes or bits) indicated as RFU shall be set to 0. 
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C1 Application Interchange Profile 


AIP Byte 1 (Leftmost) 


b8 | b7 | b6 | b5 | b4 | b3 | b2 | b1 Meaning 

0 X X X X Xx X xX | RFU 

X X X Xx X X x | SDA supported 

X X X Xx X X x | DDA supported 

bs Xx Xx 1 Xx Xx Xx X | Cardholder verification is 
supported 

x x x x 1 x x X | Terminal risk management is to 
be performed 

Xx Xx Xx Xx x 1 x xX | Issuer authentication is 
supported !9 

X X X X X X 0 xX | RFU 

X X 5 m X X X 1 | CDA supported 


AIP Byte 2 (Rightmost) 


Meaning 


Reserved for use by the EMV 
Contactless Specifications 


poppe te fe fot RFU 


x RFU 


x |x |x |x |x |x [x 
a 
oll 
Bele 
alate 
sls 
a 
ele 
es 
C 


Table 37: Application Interchange Profile 


19 When this bit is set to 1, Issuer Authentication using the EXTERNAL 
AUTHENTICATE command is supported 


Page 160 November 2011 


EMV 4.3 Book 3 Annex C Coding Data Elements Used in Trans Processing 
Application Specification C2 Application Usage Control 


C2 Application Usage Control 


Application Usage Control Byte 1 (Leftmost) 


(b8 | b7 [b6 | bS | b4 [bs | b2 | bt] Meaning 
1 x x x x x x X | Valid for domestic cash 
transactions 
Valid for international cash 
Sion 


1 ERE IESESR | x | Valid for domestic [Valid for domestic goods | 


Cae eeaeeaa —ae 
Pe PePe ToDo Pa To Pa [tien is — 
EASA EIERED | x |ValidatATMs 


Valid at terminals other than 
ATMs 


arr Usage Control Byte 2 2 eg ——— 


pb7 | be | bs | b4 | b3 | b2| bi] Meaning 
Wisicte st 
Pfs Pa Po [Po [x Pintrnatonacahback alowed 
Pepe ope [expe [xfer 
Pepe [xo [x Px fx [xfer 


Dp Pe Pfeffer 
De Pf [oP [fae 
Px px [x [x [ox Po [ x reo 
PP Po Po Po To To fro 


Table 38: Application Usage Control 
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C3 Cardholder Verification Rule Format 


CV Rule Byte 1 (Leftmost): Cardholder Verification Method (CVM) Codes 


{a 


eey cardholder verification if this 
CVM is unsuccessful 


ee | succeeding CV Rule if this 
ee | is unsuccessful 


poof fe fof francois 
Plaintext PIN verification 
performed by ICC 

Eee ee EER Enciphered PIN verified online 

1 | Plaintext PIN verification 
performed by ICC and signature 
(paper) 
1 Enciphered PIN verification 

performed by ICC 


1 1 | Enciphered PIN verification 
performed by ICC and signature 
(paper) 
Xx X Xx X X | Values in the range 000110-011101 
reserved for future use by this 
specification 


POPP P aT I [simon 


Values in the range 100000-101111 
reserved for use by the individual 
payment systems 


Values in the range 110000-111110 
reserved for use by the issuer 
ae ha a Be This value is not available for use 


Table 39: CVM Codes 
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CV Rule Byte 2 (Rightmost): Cardholder Verification Method (CVM) Condition 
Codes 


C vale [earings 
wr [awesSC—“*~*S*~*~*~—‘“—S~*~*S*S*S~S 


‘O1' If unattended cash 


'02' If not unattended cash and not manual cash and not purchase 
with cashback 


If terminal supports the CVM ?° 
If manual cash 
If purchase with cashback 


If transaction is in the application currency 2! and is under X 
value (see section 10.5 for a discussion of “X”) 


'O7' If transaction is in the application currency and is over X value 


If transaction is in the application currency and is under Y value 
(see section 10.5 for a discussion of “Y”) 


If transaction is in the application currency and is over Y value 
'80'-'FF" | Reserved for use by individual payment systems 


Table 40: CVM Condition Codes 


Note: For Condition Codes '01', '04', and '05', please refer to EMVCo General Bulletin 
No. 14 - Migration Schedule for New CVM Condition Codes. 


20 Support for a CVM is described in EMV Book 4, Section 6.3.4 first paragraph.. 


21 That is, Transaction Currency Code = Application Currency Code. 
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C4 __siIssuer Code Table Index 


Part 8 of ISO/IEC 8859 
Part 9 of ISO/IEC 8859 
'10' Part 10 of ISO/IEC 8859 


Refers to 
Part 1 of ISO/IEC 8859 
Part 2 of ISO/IEC 8859 
Part 3 of ISO/IEC 8859 
Part 4 of ISO/IEC 8859 
Part 5 of ISO/IEC 8859 
| ‘06 _| Part 6 of ISO/IEC 8859 
Part 7 of ISO/IEC 8859 
| 08 
| 0 
LL tio] 

Table 41: 


Issuer Code Table Index 
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C5 Terminal Verification Results 


TVR Byte 1: (Leftmost) 


EL BF | bs | bs {pa 1 ns [62 | ba | __Meanirg__ 


Offline data authentication was not 
performed 


PPT Pea TT [spate 
mea 


Escacse [ooaae 
Fas Reed Ee a 
Pepe [x [xp [ [oP ere 
Pp Pe PP [x [x Po rr 
= Byte 2: 


bE LET | bs | bs {pa 1s |b? | ba | ___Meanirg___ 
ICC and terminal have different 
a versions 
iso [eee ell, ee | ed | x | Expired application application 
1 PPP Ta Ts fps tio Application not yet effective 


Requested service not allowed for 
card product 


ers eee ee ee 
De Pe [Poe Pere 
Dp Pf [Pf 0 Px ere 
Pf PoP [Po [x Po rer 


Table 42: Terminal Verification Results 


22 There is no requirement in this specification for an exception file, but it is recognised 
that some terminals may have this capability. 
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TVR Byte 3: 


beer | es fe De | bs |e ee | __Meaning _ 


Cardholder verification was not 
successful 


Pega eee ee eae ce Unrecognised CVM 
1 ER ESESESES | x | PIN )PIN Try Limit exceeded Limit exceeded 


PIN entry required and PIN pad 
not present or not working 

PIN entry required, PIN pad 
aC nee but PIN was not entered 


| x |Online PINentered PIN entered 


| x. | Transaction | Transaction exceeds floor limit floor limit 


Lower consecutive offline limit 
exceeded 
Upper consecutive offline limit 
exceeded 
Transaction selected randomly for 
online processing 
Pe [Pe ea Peo[ Percnan ree transaction online 
pxfx|x|x{xfofx|x|Ru 
Df Pp [x [of fre 
Df Pf Pf PP fae SS 


Table 42: Terminal Verification Results, continued 


Page 166 November 2011 


EMV 4.3 Book 3 Annex C Coding Data Elements Used in Trans Processing 
Application Specification C5 Terminal Verification Results 


TVR Byte 5 (Rightmost): 


pbs | b7 | be | bs | b4 | bs | b2 | bt] Meaning 
puftx |x| x[ x] x |x| x [Default rDonusea | 
ae a Issuer authentication failed 


Script processing failed before final 
GENERATE AC 


Script processing failed after final 
GENERATE AC 


eee ete cs ee 

Df Pf Popo Pp fe S—S 
Def [xf Px po Pope [eS 
Pete Px [x Px fx Px fo fre 


Table 42: Terminal Verification Results, continued 
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C6 Transaction Status Information 


TSI Byte 1 (Leftmost): 


bs |b7 | be | b5 | ba | bs | b2 | ba | Meaning 

1 Xx Xx x Xx Xx X xX | Offline data authentication was 
performed 

X 1 x x Xx Xx Xx X | Cardholder verification was 
performed 

Xx Xx 1 X X X X X | Card risk management was 
performed 

X X Xx 1 Xx Xx Xx xX | Issuer authentication was 
performed 
Terminal risk management was 
Tae 


| x | Script processing was performed _| processing was performed 


Table 43: Transaction Status Information 
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Annex D Transaction Log Information 


D1 Purpose 


Provide support for accessing a transaction log file by special devices. 


D2 Conditions of Execution 


This optional function is intended to be executed by special devices. 


D3 Sequence of Execution 


This function may be executed after Application Selection. 
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D4 Description 


To get the Transaction Log information, the two following data elements are 
used: Log Entry and Log Format. 


Table 44 describes the format of the Log Entry data element (tag '9F4D'): 


Byte | Format | Length Value 
1 b 1 SFI containing the cyclic transaction log file 
2 b 1 Maximum number of records in the transaction log 
file 


Table 44: Log Entry 


Devices that read the transaction log use the Log Entry data element to 
determine the location (SFI) and the maximum number of transaction log 
records. 


The SFI shall be in the range 11 to 30. 


The Transaction Log records shall be accessible using the READ RECORD 
command as specified in section 6.5.11. The file is a cyclic file as defined in 
ISO/IEC 7816-4. Record #1 is the most recent transaction. Record #2 is the next 
prior transaction, etc. 


The Transaction Log records shall not be designated in the Application File 
Locator. Each record is a concatenation of the values identified in the Log Format 
data element. The records in the file shall not contain the Application 
Elementary File (AEF) Data Template (tag '70'). 


The Log Format and the Transaction Log records shall remain accessible when 
the application is blocked. 


To read the transaction log information, the special device uses the following 
steps: 


e Perform Application Selection and retrieve the Log Entry data element 
located in the FCI Issuer Discretionary Data. If the Log Entry data element is 
not present, the application does not support the Transaction Log function. 


e Issue a GET DATA command to retrieve the Log Format data element. 
e Issue READ RECORD commands to read the Transaction Log records. 
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D5 Example 


D5 Example 


Note that the following data elements are shown for example purposes only. 


A Log Entry data element equal to '0F14' indicates that the transaction log file is 


located in SFI 15 (‘OF") and contains a maximum of 20 records (‘14’). 


A Log Format data element equal to '9A039F21035F2A029F02069F4E149F3602' 


indicates that the transaction log records have the following content: 


Data Content Tag Length 
Transaction Date 'QA' 3 
Transaction Time 'OF21' 3 
Transaction Currency Code 'BF2A' 2 
Amount, Authorised '9F02' 6 
Merchant Name and Location 'OF4E' 20 
Application Transaction Counter '9F36' 2 


Table 45: Example of Log Format 


In Table 45, lengths and tags are shown for clarity. They do not appear in the log 


record which is the concatenation of values (no TLV coding). 


Data elements listed in the Log Format may come from the terminal and the 
card. Terminal data elements such as Merchant Name and Location might have 


been passed to the card in the PDOL or CDOL data. 
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Annex E TVR and TSI Bit Settings Following 
Script Processing 


Four possible scenarios can occur when processing a script. These scenarios are 
described below, together with the expected results in terms of the setting of the 
appropriate TVR bits, the TSI bit, and the Issuer Script Results. 


In the following descriptions: 


e “TVR bits” refers to TVR byte 5 bit 6 and bit 5 (depending on whether it is a 
tag '71' and/or tag '72' script) as defined in Table 42. 


e “TSI bit” refers to TSI byte 1 bit 3 as defined in Table 43. 
The Issuer Script Results are defined in Book 4, Annex A5. 


E1 Scenarios 


Scenario 1 


A script is received, it parses correctly, the commands are sent to the card, and 
the card returns '9000'", '62xx', or '63xx' to all commands received. 


In this scenario the terminal: 
e shall set the TSI bit 
e shall not set the TVR bits 


e shall set the first byte of the Issuer Script Results to '2x', ‘Script processing 
successful’. 
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Scenario 2 


A script is received, it parses correctly, the commands are sent to the card, but 
the card does not return '9000'" '62xx', or '63xx' to one of the commands received. 


In this scenario the terminal: 
e shall set the TSI bit 
e shall set the appropriate TVR bit(s) 


e shall set the first byte of the Issuer Script Results to '1x', ‘Script processing 
failed’ 


e shall send no further commands from that script to the card, even if they 
exist. 
Scenario 3 


A script is received, it does not parse correctly, and so no commands are sent to 
the card. 


In this scenario the terminal: 

e shall set the TSI bit 

e shall set the appropriate TVR bit(s) 

e shall set the first byte of the Issuer Script Results to '00', ‘Script not 
performed’. 

Scenario 4 


No script is received. In this scenario the terminal shall set neither the TSI bit 
nor the TVR bit(s). 


In this event there will be no Issuer Script Results. 
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E2 Additional Information 


It is possible, but not reeommended, that commands may be sent to the card ‘on 
the fly’ as a script is parsed. In this event: 


e Ifa parsing error occurs before any commands are sent to the card, the 
terminal shall set the first byte of the Issuer Script Results to '00' and shall 
set the appropriate TVR bits and the TSI bit. 


e Ifa parsing error occurs after any command has been sent to the card, the 
terminal shall set the first byte of the Issuer Script Results to '1x', and shall 
set the appropriate TVR bits and the TSI bit. 


If more than one script is received, the terminal: 
e shall set the TSI bit 
e shall set the TVR bit(s) (as described in Scenarios 2 and 8) if any error occurs 


e shall set the Issuer Script Results as described in Scenarios 1 through 3 for 
each script on a script-by-script basis 


e shall process all Issuer scripts 
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Annex F 


Status Words Returned In 
EXTERNAL AUTHENTICATE 


The terminal shall issue an EXTERNAL AUTHENTICATE command to the card 
only if the card indicates in byte 1 bit 3 of the AIP that it supports issuer 
authentication using the EXTERNAL AUTHENTICATE command. 


The terminal shall issue only one EXTERNAL AUTHENTICATE command to 
the card during a transaction. As stated in section 10.9, there is a complementary 
card requirement to this which states that the card shall return status '6985', 
‘Command Not Supported’, to the second and any subsequent EXTERNAL 
AUTHENTICATE commands received during the transaction. 


Table 46 explains various status values the terminal may receive in response to 
the (first) EXTERNAL AUTHENTICATE command issued to the card, and the 
action the terminal shall take as a result. 


Status Explanation Terminal Action 
'9000' Issuer authentication The terminal shall continue with 
was successful. the transaction. 
'6300' or any Issuer authentication The terminal shall set the ‘Issuer 


other status 
except '6985' 
and '9000' 


failed. 


authentication failed’ bit in the 
TVR to 1, and continue with the 
transaction. 


'6985' 


Issuer authentication 
failed and the card is in 
an error state (it has 
indicated in the AIP that 
it supports EXTERNAL 
AUTHENTICATE, but in 
the status returned that 
it does not). 


This condition should never occur; 
in the event that it does, the 
behaviour of the terminal is 
indeterminate and it shall either 
terminate the transaction OR set 
the ‘Issuer authentication failed’ 
bit in the TVR to 1, and continue 
with the transaction. 


Table 46: Terminal Action after (First) EXTERNAL AUTHENTICATE Response 
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Annex G Account Type 


f 00 Default - unspecified 


All other 
values RFU 


Table 47: Account Type 
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Part V 


Common Core 
Definitions 


November 2011 


Page 181 


EMV 4.3 Book 3 
Application Specification 


Introduction 


This Part describes an optional extension to this Book, to be used when 
implementing the Common Core Definitions (CCD). 


These Common Core Definitions specify a minimum common set of card 
application implementation options, card application behaviours, and data 
element definitions sufficient to accomplish an EMV transaction. Terminals 
certified to be compliant with the existing EMV Specifications will, without 
change, accept cards implemented according to the Common Core Definitions, 
since the Common Core Definitions are supported within the existing EMV 
requirements. 


To be compliant with the Common Core Definitions, an implementation shall 
implement all the additional requirements in the Common Core Definitions Parts 
of all affected Books. 


Changed and Added Sections 


Each section heading below refers to the section in this Book to which the 
additional requirements apply, or introduces new sections where required. The 
text defines requirements for a common core implementation, in addition to the 
requirements already specified in the referenced section of EMV. 
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Part Il - Data Elements and Commands 


6 Commands for Financial Transaction 


6.2 Response APDU Format 


For the following commands used during transaction processing, the body of the 
response APDU is a constructed data object with tag equal to '77' of which the 
value field may contain one or more BER-TLV coded data objects. 


e GENERATE AC 
e GET PROCESSING OPTIONS 
INTERNAL AUTHENTICATE 


Response Message Template Format 2 


Table CCD 1: Body of Response APDU Structure 


6.5 Commands 
6.5.4 EXTERNAL AUTHENTICATE Command-Response APDUs 


6.5.4.1 Definition and Scope 


The CCD-compliant application shall support issuer authentication using the 
second GENERATE AC command. The CCD-compliant application shall indicate 
that the EXTERNAL AUTHENTICATE command is not supported in EMV 
applications by setting bit 3 in byte 1 of the AIP to 0. 


6.5.5 GENERATE APPLICATION CRYPTOGRAM Command-Response 
APDUs 

6.5.5.1 Definition and Scope 

The CCD-compliant application shall support issuer authentication using the 
second GENERATE AC command. 

6.5.5.3 Data Field Sent in the Command Message 


CDOL2 shall include tag '8A' (Authorisation Response Code) and tag '91' (Issuer 
Authentication Data). 
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6.5.5.4 Data Field Returned in the Response Message 


The response message shall be a BER-TLV coded constructed data object 
introduced by tag '77' and contains only the data shown in Table CCD 2. 


'QF27' Cryptogram Information Data 
'9F36' Application Transaction Counter 


'9F26' Application Cryptogram 
‘OF 10' Issuer Application Data 


Table CCD 2: Format 2 GENERATE AC Response Message Data Field 


The required data elements for the response returned in an envelope as specified 
for the CDA feature (described in section 6.6 of Book 2) are shown in Book 2 
Table CCD 1 and Table CCD 2. 


The Cryptogram Information Data returned in the GENERATE AC response 
message is coded according to Table CCD 3: 


RFU 


Payment System-specific cryptogram 
No advice required 


No information given 


Table CCD 3: Coding of Cryptogram Information Data 
6.5.8 GET PROCESSING OPTIONS Command-Response APDUs 


6.5.8.2 Command Message 


The CCD-compliant application shall not preclude support for PDOL. 
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6.5.8.4 Data Field Returned in the Response Message 


The response message shall be a BER-TLV coded constructed data object 
introduced by tag '77' and contains only the data shown in Table CCD 4. 


Application Interchange Profile 


Application File Locator 


Table CCD 4: Format 2 GET PROCESSING OPTIONS Response Message Data 
Field 


6.5.9 INTERNAL AUTHENTICATE Command-Response APDUs 


6.5.9.4 Data Field Returned in the Response Message 


The response message shall be a BER-TLV coded constructed data object 
introduced by tag '77' and contains only the data shown in Table CCD 5. 


Tag Value 
'9F4B' | Signed Dynamic Application Data 


Table CCD 5: Format 2 Internal Authenticate Response Message Data Field 


6.5.12.2 Command Message 


To allow an issuer to use offline plaintext PIN verification as a possible CVM, a 
CCD-compliant card shall support the VERIFY command with parameter 
P2 = ‘80’ as defined in Book 3, Table 23. 
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Part Ill - Debit and Credit Application 
Specification 


7 Files for Financial Transaction Interchange 


7.3 Data Retrievable by GET DATA Command 


The ICC shall support the GET DATA command for retrieval of the primitive 
data object with tag '9F17' (PIN Try Counter). 
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9 GENERATE AC Command Coding 


9.2 Command Data 


9.2.2 Transaction Certificate Data 


The CCD-compliant application shall not contain a TDOL. The CCD-compliant 
application shall not request the terminal to generate a TC Hash Value (that is, 
tag '98' shall not be included in CDOL1 or CDOL2). 


The following Section 9.2.3 applies to a CCD-compliant application. 


9.2.3 Common Core Definitions Card Verification Results 


In response to the GENERATE AC command and as part of the Issuer 
Application Data, the CCD-compliant application shall return the Card 
Verification Results (CVR). The CVR includes information for the issuer 
regarding the results of Card Risk Management processing and application 
processing. The format of the CVR for a CCD-compliant application is specified in 
CCD Annex C7.3. 


9.2.3.1 Options Related to Setting/Resetting of Counters and Indicators 


The issuer shall have the option of specifying whether a new card is required to 
set the ‘Go Online on Next Transaction Was Set’ bit. 


The issuer shall have the option of specifying whether the CCD-compliant 
application requires issuer authentication to be performed for the application to 
approve (TC) an online transaction. 


The issuer shall have the option of specifying whether the CCD-compliant 
application requires issuer authentication to pass when performed for the 
application to approve (TC) an online transaction. 


If the CCD-compliant application does not require issuer authentication to be 
performed for the application to approve (TC) an online transaction, the issuer 
shall have the option of specifying whether the CCD-compliant application 
requires issuer authentication to pass for resetting all the following 
non-velocity-checking indicators: 


e Issuer Authentication Failed 
e Last Online Transaction Not Completed 
e Issuer Script Processing Failed 


e Go Online on Next Transaction Was Set 
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If the CCD-compliant application does not require issuer authentication to pass 
when performed for the application to approve (TC) an online transaction, the 
issuer shall have the option of specifying whether the CCD-compliant application 
requires issuer authentication to pass for resetting all the following non-velocity 
checking indicators: 


e Last Online Transaction Not Completed 
e Issuer Script Processing Failed 
e Go Online on Next Transaction Was Set 


If the CCD-compliant application does not require issuer authentication to be 
performed or does not require issuer authentication to pass when performed for 
the application to approve (TC) an online transaction, the issuer shall have the 
option of specifying whether the CCD-compliant application requires issuer 
authentication to pass for resetting the velocity-checking offline transaction 
count(s) and cumulative amount(s). 


The issuer shall have the option of indicating whether the application shall use 
the ‘Update Counters’ bits in the CSU to update the velocity-checking count(s) 
and cumulative amount(s) associated with the offline transaction limits referred 
to in bits b8 - b5 of byte 3 of the CVR, if the ‘CSU Created by Proxy for the Issuer’ 
bit in the CSU is set to 1. 


If the ‘CSU Created by Proxy for the Issuer’ bit is set to 1 in the CSU, and if the 
issuer specifies that ‘Update Counters’ shall not be used, then the issuer shall 
have the option of indicating whether the application: 


e shall not update the offline counters 
e shall set the offline counters to zero 
e shall set the offline counters to the upper offline limits 


e shall add the transaction to the offline counter(s) 


9.2.3.2 Setting and Resetting of Bits in the CVR 

The following describes the conditions under which each bit in the CVR of a 
Common Core Definitions card is set or reset. 

Application Cryptogram Type Returned in Second GENERATE AC 


In the first GENERATE AC response, these bits shall be set to Second 
GENERATE AC Not Requested. 


In the second GENERATE AC response, these bits shall be set to the value of bits 
b8 — b7 of the Cryptogram Information Data returned in the response to the 
second GENERATE AC command of the current transaction (AAC or TC). 
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Application Cryptogram Type Returned in First GENERATE AC 


In both the first and second GENERATE AC response, these bits shall be set to 
the value of bits b8 — b7 of the Cryptogram Information Data returned in the 
response to the first GENERATE AC command of the current transaction (AAC, 
TC, or ARQC). 


CDA Performed 


In the first GENERATE AC response, this bit shall be set if and only if Signed 
Dynamic Data is returned in the response to the first GENERATE AC command 
of the current transaction. 


In the second GENERATE AC response, this bit shall be set if and only if Signed 
Dynamic Data is returned in the response to the first or second GENERATE AC 
command (or both) of the current transaction. 


Offline DDA Performed 


In both the first and second GENERATE AC response, this bit shall be set if and 
only if Signed Dynamic Application Data is returned in the response to the 
INTERNAL AUTHENTICATE command of the current transaction. 


Issuer Authentication Not Performed 


In the second GENERATE AC response, this bit shall be set if and only if the 
CCD-compliant application did not receive Issuer Authentication Data. This may 
be the case either if the transaction was unable to go online or if the issuer did 
not provide Issuer Authentication Data in the response message. 


In the first GENERATE AC response, this bit shall be set to the value it had in 
the most recent second GENERATE AC response sent by the CCD-compliant 
application. 
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Issuer Authentication Failed 


This bit shall be set in the GENERATE AC response if and only if issuer 
authentication was performed and failed. In the first GENERATE AC response, 
it indicates issuer authentication failed in a previous online transaction. In the 
second GENERATE AC response, it indicates either that issuer authentication 
failed in the current transaction, or that issuer authentication failed in a 
previous transaction and the bit was not reset. 


Once set, this bit shall remain set until either: 
e issuer authentication is successful, 
e or all of the following conditions are true: 


« the transaction successfully went online (that is, the Authorisation 
Response Code does not indicate that the terminal was unable to go 
online), 


"issuer authentication was not performed, 


" the CCD-compliant application does not require issuer authentication to 
be performed for the application to approve (TC) an online transaction, 
and 


"the CCD-compliant application does not require issuer authentication to 
pass for resetting of non-velocity-checking indicators. 
Low Order Nibble of PIN Try Counter 
In both the first and second GENERATE AC response, these bits shall be set to 
the value of the low-order nibble (bits b4-b1) of the PIN Try Counter. 
Offline PIN Verification Performed 


In both the first and second GENERATE AC response, this bit shall be set if and 
only if Offline PIN Verification has been performed (successfully or 
unsuccessfully) on the current transaction. 


Offline PIN Verification Performed and PIN Not Successfully Verified 


In both the first and second GENERATE AC response, this bit shall be set if and 
only if Offline PIN Verification has been performed on the current transaction 
and the PIN was not successfully verified during processing of the current 
transaction. 


PIN Try Limit Exceeded 


In both the first and second GENERATE AC response, this bit shall be set if and 
only if the PIN Try Counter is zero. 
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Last Online Transaction Not Completed 


This bit shall be set in the first GENERATE AC response if and only if in the 
previous transaction, the CCD-compliant application requested to go online and 
the transaction was not completed (that is, the second GENERATE AC command 
was not received). 


Once set, this bit shall remain set until either: 
e issuer authentication is successful, 
e or all of the following conditions are true: 


« the transaction successfully went online (that is, the Authorisation 
Response Code does not indicate that the terminal was unable to go 
online), 


"issuer authentication was not performed, 


" the CCD-compliant application does not require issuer authentication to 
be performed for the application to approve (TC) an online transaction, 
and 


"the CCD-compliant application does not require issuer authentication to 
pass for resetting of non-velocity-checking indicators. 


e or all of the following conditions are true: 


« the transaction successfully went online (that is, the Authorisation 
Response Code does not indicate that the terminal was unable to go 
online), 


"issuer authentication was performed and failed, 


" the CCD-compliant application does not require issuer authentication to 
pass when performed for the application to approve (TC) an online 
transaction, and 


" the CCD-compliant application does not require issuer authentication to 
pass for resetting of non-velocity-checking indicators. 


Lower Offline Transaction Count Limit Exceeded 


In both the first and second GENERATE AC response, this bit shall be set if the 
CCD-compliant application has exceeded an issuer-specified lower limit for the 
number of transactions approved offline. This bit may represent the condition of 
multiple counters. At the least, all transactions approved offline whose amounts 
were not cumulated shall be included in at least one transaction count. This bit 
may also be set under additional conditions specified by the issuer. 
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Upper Offline Transaction Count Limit Exceeded 


In both the first and second GENERATE AC response, this bit shall be set if the 
CCD-compliant application has exceeded an issuer-specified upper limit for the 
number of transactions approved offline. This bit may represent the condition of 
multiple counters. At the least, all transactions approved offline whose amounts 
were not cumulated shall be included in at least one transaction count. This bit 
may also be set under additional conditions specified by the issuer. 


Lower Cumulative Offline Amount Limit Exceeded 


In both the first and second GENERATE AC response, this bit shall be set if the 
CCD-compliant application has exceeded an issuer-specified lower limit for 
cumulative amounts approved offline. This bit may represent the condition of 
multiple counters. At the least, all domestic transactions approved offline shall 
be included in at least one cumulative amount. This bit may also be set under 
additional conditions specified by the issuer. 


Upper Cumulative Offline Amount Limit Exceeded 


In both the first and second GENERATE AC response, this bit shall be set if the 
CCD-compliant application has exceeded an issuer-specified upper limit for 
cumulative amounts approved offline. This bit may represent the condition of 
multiple counters. At the least, all domestic transactions approved offline shall 
be included in at least one cumulative amount. This bit may also be set under 
additional conditions specified by the issuer. 


Issuer-discretionary bit 1 — Issuer-discretionary bit 4: 


These bits are set in the first and second GENERATE AC response at the 
discretion of the issuer. The meaning of these bits is defined by the issuer and is 
outside the scope of this specification. 


Number of Successfully Processed Issuer Script Commands Containing 
Secure Messaging 


In the first and second GENERATE AC response, these bits shall be set to the 
number of commands successfully processed with secure messaging. 
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Issuer Script Processing Failed 


In both the first and second GENERATE AC response, this bit shall be set if and 
only if processing of a command with secure messaging failed. 


Once set, this bit shall remain set until a subsequent GENERATE AC command 
where either: 


e issuer authentication is successful, 
e or all of the following conditions are true: 


« the transaction successfully went online (that is, the Authorisation 
Response Code does not indicate that the terminal was unable to go 
online), 


"issuer authentication was not performed 


" the CCD-compliant application does not require issuer authentication to 
be performed for the application to approve (TC) an online transaction, 
and 


"the CCD-compliant application does not require issuer authentication to 
pass for resetting of non-velocity-checking indicators. 


e or all of the following conditions are true: 


« the transaction successfully went online (that is, the Authorisation 
Response Code does not indicate that the terminal was unable to go 
online), 


"issuer authentication was performed and failed, 


" the CCD-compliant application does not require issuer authentication to 
pass when performed for the application to approve (TC) an online 
transaction, and 


" the CCD-compliant application does not require issuer authentication to 
pass for resetting of non-velocity-checking indicators. 
Offline Data Authentication Failed on Previous Transaction 


In both the first and second GENERATE AC response, this bit shall be set if and 
only if, in the TVR returned during the previous transaction, any of the following 
bits was set: 


e SDA Failed 
e DDA Failed 
e CDA Failed 


Once set, this bit shall remain set until a subsequent transaction is performed 
that meets either of the following conditions: 


e the previous transaction successfully went online, or 


e the previous transaction was approved offline. 
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If either condition is met the bit is reset in the first GENERATE AC response. 


Go Online on Next Transaction Was Set 


In both the first and second GENERATE AC response, this bit shall be set if and 
only if the ‘Set Go Online on Next Transaction’ bit of the last successfully 
recovered CSU was set, or it is a new card and the issuer has specified that a new 
card is required to set the ‘Go Online on Next Transaction Was Set’ bit. 


Once set, this bit shall remain set until a subsequent GENERATE AC command 
where either: 


e all of the following conditions are true: 

=" issuer authentication is successful, and 

«the Set Go Online on Next Transaction bit of the CSU is not set. 
e or all of the following conditions are true: 


« the transaction successfully went online (that is, the Authorisation 
Response Code does not indicate that the terminal was unable to go 
online), 


"issuer authentication was not performed, 


"the CCD-compliant application does not require issuer authentication to 
be performed for the application to approve (TC) an online transaction, 
and 


" the CCD-compliant application does not require issuer authentication to 
pass for resetting of non-velocity-checking indicators. 


e or all of the following conditions are true: 


« the transaction successfully went online (that is, the Authorisation 
Response Code does not indicate that the terminal was unable to go 
online), 


"issuer authentication was performed and failed, 


" the CCD-compliant application does not require issuer authentication to 
pass when performed for the application to approve (TC) an online 
transaction, and 


"the CCD-compliant application does not require issuer authentication for 
resetting of non-velocity-checking indicators. 
Unable to go Online 


This bit shall be set in the second GENERATE AC response if and only if the 
Authorization Response Code, tag '8A', returned from the terminal indicates the 
terminal was unable to go online (set to 'Y3' or 'Z3'). 
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9.2.3.3 Mandatory Actions Due to CVR Bit Settings 


This section provides a list of mandatory actions that shall be taken by the 
CCD-compliant application, and issuer-configurable options that shall be 
supported by the CCD-compliant application. 

Issuer Authentication Not Performed 


The issuer shall have the option of specifying that if this bit is set, whether the 
CCD-compliant application shall: 


e force transactions at online-capable terminals to go online, 
e or allow the transaction to remain offline. 


The issuer shall have the option of specifying that if this bit is set, and either the 
transaction occurs at an offline-only terminal or the terminal is unable to go 
online, whether the CCD-compliant application shall: 


e be allowed to approve (TC) the transaction, or 


e decline the transaction. 


Issuer Authentication Failed 


The issuer shall have the option of specifying that if this bit is set, whether the 
CCD-compliant application shall: 


e force transactions at online-capable terminals to go online, 
e or allow the transaction to remain offline. 


The issuer shall have the option of specifying that if this bit is set, and either the 
transaction occurs at an offline-only terminal or the terminal is unable to go 
online, whether the CCD-compliant application shall: 


e be allowed to approve (TC) the transaction, or 


e decline the transaction. 


PIN Try Limit Exceeded 


The issuer shall have the option of specifying that if this bit is set, the 
CCD-compliant application shall decline the transaction offline. 


The issuer shall have the option of specifying that if this bit is set, whether the 
CCD-compliant application shall: 


e force transactions at online-capable terminals to go online, 


e or allow the transaction to remain offline. 
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The issuer shall have the option of specifying that if this bit is set, and either the 
transaction occurs at an offline-only terminal or the terminal is unable to go 
online, whether the CCD-compliant application shall: 


e be allowed to approve (TC) the transaction, or 
e decline the transaction. 


The ICC shall not block the application or the card due to this bit being set. 


Last Online Transaction Not Completed 


If this bit is set, the CCD-compliant application shall force the transaction at 
online-capable terminals to go online. 


The issuer shall have the option of specifying that if this bit is set, and either the 
transaction occurs at an offline-only terminal or the terminal is unable to go 
online, whether the CCD-compliant application shall: 


e be allowed to approve (TC) the transaction, or 


e decline the transaction. 


Lower Offline Transaction Count Limit Exceeded 


If this bit is set in the first GENERATE AC response, the CCD-compliant 
application shall force the transaction at online-capable terminals to go online. 


Upper Offline Transaction Count Limit Exceeded 


If this bit is set and either the transaction occurs at an offline-only terminal or 
the terminal is unable to go online, the CCD-compliant application shall decline 
the transaction. However, the issuer shall have the option of allowing the 
CCD-compliant application to override this decline for a transaction at Terminal 
Type 26. 


Lower Cumulative Offline Amount Limit Exceeded 

If this bit is set in the first GENERATE AC response, the CCD-compliant 
application shall force the transaction at online-capable terminals to go online. 
Upper Cumulative Offline Amount Limit Exceeded 


If this bit is set and either the transaction occurs at an offline-only terminal or 
the terminal is unable to go online, the CCD-compliant application shall decline 
the transaction. However, the issuer shall have the option of allowing the 
CCD-compliant application to override this decline for a transaction at Terminal 
Type 26. 


Issuer Script Processing Failed 


The issuer shall have the option of specifying that if this bit is set, whether the 
CCD-compliant application shall: 
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e force transactions at online-capable terminals to go online, 


e or allow the transaction to remain offline. 


Go Online on Next Transaction Was Set 


The issuer shall have the option of specifying that if this bit is set, and either the 
transaction occurs at an offline-only terminal or the terminal is unable to go 
online, whether the CCD-compliant application shall: 


e be allowed to approve (TC) the transaction, or 


e decline the transaction. 


9.3 Command Use 


The CCD-compliant application shall respond to the first GENERATE AC with 
any of the following cryptogram types: 


e TC 
ARQC 
AAC 


The CCD-compliant application shall respond to the second GENERATE AC (if 
applicable) with either of the following cryptogram types: 


e TC 
AAC 
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10 Functions Used in Transaction Processing 


10.5 Cardholder Verification 


The CCD-compliant application shall support Cardholder Verification. It shall 
indicate this by setting the Application Interchange Profile byte 1, bit 5 to 1. 
10.5.1 Offline PIN Processing 


The CCD-compliant application shall be capable of supporting offline plaintext 
PIN verification. It is the issuer’s option whether or not to use offline plaintext 
PIN as a cardholder verification method. 


10.8 Card Action Analysis 


The CCD-compliant application shall not request that the terminal send an 
advice message to the issuer. 

10.8.1 Terminal Messages for an AAC 

The CCD-compliant application shall set bits b3-b1 of the CID to '000' in the 
GENERATE AC command response. 

10.8.2 Advice Messages 


The CCD-compliant application shall not request the terminal to send an advice 
message. Bit b4 of the Cryptogram Information Data shall be set to 0. 


10.10 Issuer-to-Card Script Processing 


An issuer shall send no more than one issuer script template in an authorization 
response message. The script template may contain multiple commands. The 
script template may be tag '71' or tag '72'. 
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10.11 Completion 


The following Section 10.11.1 applies to a CCD-compliant application. 


10.11.1 Additional Completion Actions for a CCD-Compliant Application 


10.11.1.1 Actions Taken by CCD-compliant Application After Issuer 
Authentication is Successful 


After issuer authentication is successful, if the ‘CSU Created by Proxy for the 
Issuer’ bit in the CSU 1s set to 1, and if the issuer specifies that ‘Update 
Counters’ shall not be used, then the following shall govern the behaviour of 
velocity-checking counters and cumulative amounts associated with the offline 
transaction limits referred to in bits b8-b5 of byte 3 of the CVR: 


e Ifthe issuer specifies that the application shall not update the offline 
counters, no offline counter or cumulative amount is modified. 


e Ifthe issuer specifies that the application shall set the offline counters to 
zero, the application will reset all the offline counters and cumulative 
amounts to zero. By doing so, the issuer allows the application to accept 
offline transactions, up to the offline limits. 


e Ifthe issuer specifies that the application shall set the offline counters to the 
upper offline limits, the offline counters and cumulative amounts will be set 
to their respective upper limits. 


e Ifthe issuer specifies that the application shall add the transaction to the 
offline counter(s), the transaction will be included in the offline counters or 
cumulative amounts as if it were an offline transaction. 


This section describes the actions to be taken by the CCD-compliant application 
due to the setting of each bit in the CSU after issuer authentication is successful. 
Issuer Approves Online Transaction 


If ‘Issuer Approves Online Transaction’ is set and the terminal requests a TC, the 
application shall approve the transaction by returning a TC. 


If ‘Issuer Approves Online Transaction’ is not set, the application shall decline 
the transaction by returning an AAC. 


Card Block 


If ‘Card Block’ is set, all applications in the ICC shall be permanently disabled, 
including applications that may be selected implicitly. For all subsequent 
SELECT commands the card shall return the status bytes ‘Function not 
supported’ (SW1-SW2 = '6A81') and perform no other action. 
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Application Block 


If ‘Application Block’ is set, the currently selected application shall be 
invalidated. An invalidated application shall return the status bytes ‘Selected file 
invalidated’ (SW1-SW2 = '6283') in response to a SELECT command and return 
only an AAC in response to the GENERATE AC command. 


Update PIN Try Counter 


If ‘Update PIN Try Counter’ is set, the application shall update the PIN Try 
Counter (PTC) with the value contained in bits b4-b1 of byte 1 of the CSU. If the 
PIN is blocked, updating the value of the PTC with a non-zero value unblocks the 
PIN. Updating the value of the PTC with a zero value blocks the PIN. 


If ‘Update PIN Try Counter’ is not set, no update of the PTC shall be performed 
by the application. 


The value contained in bits b4-b1 of byte 1 of the CSU shall never be interpreted 
by the application. 


Set Go Online on Next Transaction 


If ‘Set Go Online on Next Transaction’ is set, the application shall force 
subsequent transactions at online-capable terminals to go online (that is, the 
CCD-compliant application shall return an ARQC in response to the first 
GENERATE AC command if a TC or an ARQC is requested). The application 
shall continue to try to go online at online-cable terminals until a subsequent 
GENERATE AC command where either: 


e all of the following conditions are true: 

=" issuer authentication is successful, and 

«the Set Go Online on Next Transaction bit of the CSU is not set. 
e or all of the following conditions are true: 


« the transaction successfully went online (that is, the Authorisation 
Response Code does not indicate that the terminal was unable to go 
online), 


"issuer authentication was not performed, 


" the CCD-compliant application does not require issuer authentication to 
be performed for the application to approve (TC) an online transaction, 
and 


" the CCD-compliant application does not require issuer authentication to 
pass for resetting of non-velocity-checking indicators.” 


e or all of the following conditions are true: 


« the transaction successfully went online (that is, the Authorisation 
Response Code does not indicate that the terminal was unable to go 
online), 
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"issuer authentication was performed and failed, 


" the CCD-compliant application does not require issuer authentication to 
pass when performed for the application to approve (TC) an online 
transaction, and 


" the CCD-compliant application does not require issuer authentication to 
pass for resetting of non-velocity-checking indicators. 


Update Counters 


‘Update Counters’ (bits b2-b1 of byte 2 of the CSU) govern the behaviour of 
velocity-checking counters and cumulative amounts associated with the offline 
transaction limits referred to in bits b8-b5 of byte 3 of the CVR if either of the 
following is true: 


e the ‘CSU Created by Proxy for the Issuer’ bit in the CSU is set to 0 


e the issuer specifies that the application shall use the ‘Update Counters’ bits 
in the CSU to update the velocity-checking count(s) and cumulative 
amount(s) regardless of the bit setting for ‘CSU Created by Proxy for the 
Issuer’ 


If ‘Update Counters’ is set to ‘Do Not Update Offline Counters’, no offline counter 
or cumulative amount shall be modified. 


If ‘Update Counters’ is set to ‘Reset Offline Counters to Zero’, the application 
shall reset all the offline counters and cumulative amounts to zero. By doing so, 
the issuer allows the application to accept offline transactions, up to the offline 
limits. 


If ‘Update Counters’ is set to ‘Set Offline Counters to Upper Offline Limits’, the 
application shall set the offline counters and cumulative amounts to their 
respective upper limits. 


If ‘Update Counters’ is set to ‘Add Transaction to Offline Counters’, the 
application shall include the transaction in the offline counters or cumulative 
amounts as if it were an offline transaction. 


10.11.1.2 Other Completion Actions 


After the transaction successfully went online (that is, the Authorisation 
Response Code does not indicate that the terminal was unable to go online), the 
CCD-compliant application shall reset to zero the velocity-checking offline 
transaction count(s) and cumulative offline amount(s) if either of the following 
are true: 


e all of the following conditions are true: 
«" the terminal requested a TC, 


"issuer authentication was not performed, 
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"the CCD-compliant application does not require issuer authentication to 
be performed for the application to approve (TC) an online transaction, 
and 


" the CCD-compliant application does not require issuer authentication to 
pass for resetting of velocity-checking counters. 


e or all of the following conditions are true: 
« the terminal requested a TC, 
"issuer authentication was performed and failed, 


"the CCD-compliant application does not require issuer authentication to 
pass when performed for the application to approve (TC) an online 
transaction, and 


" the CCD-compliant application does not require issuer authentication to 
pass for resetting of velocity-checking counters. 


After the transaction successfully went online (that is, the Authorisation 
Response Code does not indicate that the terminal was unable to go online), the 
CCD-compliant application shall approve the transaction if all of the following 
conditions are true: 


e the terminal requested a TC, and 
e one of the following is true: 


"issuer authentication is successful and the ‘Issuer Approves Online 
Transaction bit’ of the recovered CSU is set to 1, or 


"issuer authentication was not performed and the CCD-compliant 
application does not require issuer authentication to be performed for the 
application to approve (TC) an online transaction, or 


" issuer authentication was performed and failed and the CCD-compliant 
application does not require issuer authentication to pass when performed 
for the application to approve (TC) an online transaction. 


After the transaction successfully went online (that is, the Authorisation 
Response Code does not indicate that the terminal was unable to go online), the 
CCD-compliant application shall decline the transaction in the second 
GENERATE AC response if either of the following conditions are true: 


e both of the following are true: 
"issuer authentication was not performed, and 


" the CCD-compliant application requires issuer authentication to be 
performed for the application to approve (TC) an online transaction, 


e or both of the following are true: 


"issuer authentication was performed and failed, and 
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" the CCD-compliant application requires issuer authentication to pass 
when performed for the application to approve (TC) an online transaction. 


After the transaction did not successfully complete online (that is the 
Authorisation Response Code indicates that the terminal was unable to go 
online), the CCD-compliant application shall decide whether to approve or 
decline the transaction. 


Part IV - Annexes 


Annex A_ Data Elements Dictionary 


For the data elements shown in Table CCD 6: 


e Ifthe source is ‘Terminal’, the data element shall not be included in any DOL 
used by a CCD-compliant application. 


e Ifthe source is ‘ICC’, the data element shall not be identified in the AFL of a 
CCD-compliant application. 


Amount, Reference Currency 'OF3A' Terminal 
Application Reference Currency 'OF3B' 


Application Reference Currency Exponent ‘OF 43' 


Default Dynamic Data Authentication Data Terminal 
Object List (DDOL) 


Transaction Certificate (TC) Hash Value Terminal 


Table CCD 6: Data Elements Not Used by a CCD-Compliant Application 


Table CCD 7 lists data elements (in addition to those defined in Annex A) that 
are defined within the context of the Common Core Definitions. 
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Name 


Card 
Verification 
Results (CVR) 


Common Core 
Identifier 
(CCI) 


Derivation 
Key Index 
(DKI) 


Issuer 
Discretionary 
Data 


Description 


Contains data sent to the 
issuer indicating exception 
conditions that occurred 
during the current and 
previous transactions. 
Transmitted to the 
terminal in Issuer 
Application Data as 
specified in Table CCD 9. 


Data sent to the issuer 
identifying the format of 
the Issuer Application 
Data and the method for 
calculating the Application 
Cryptogram. Transmitted 
to the terminal in Issuer 
Application Data as 
specified in Table CCD 9. 
Contains the following: 


Format Code (FC) 


Cryptogram Version 


(CV) 


Data sent to the issuer 
identifying the issuer’s 
derivation key for deriving 
the card’s ICC Master 
Keys. Transmitted to the 
terminal in Issuer 
Application Data as 
specified in Table CCD 9. 


Contains issuer 
proprietary application 
data for transmission to 
the issuer in an online 
transaction. Transmitted 
to the terminal in Issuer 
Application Data as 
specified in Table CCD 9. 


a: Leng 
th 


Table CCD 7: Additional Data Elements Defined for CCD 
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Annex C Coding of Data Elements Used in 
Transaction Processing 


Please add the following sections after Annex C.6. 


C7 Issuer Application Data for a Common Core Definitions- 
Compliant Application 


The CCD-compliant application shall have an Issuer Application Data (IAD) field 
of fixed length, 32 bytes long, with the following attributes: 

e Byte 1 shall be set to 'OF". 

e Byte 2 shall be the Common Core Identifier (CCI). 

e Byte 17 shall be set to 'OF". 


The CCD-compliant application shall support the selection of different Issuer 
Application Data if: 


e the card requests the Terminal Type and the Additional Terminal 
Capabilities in PDOL, and 


e the values provided by the terminal in the PDOL related data for the 
Terminal Type and the first two bytes of the Additional Terminal Capabilities 
are '34’ and '0000' respectively. 


C7.1 Common Core Identifier 


The CCI shall identify the format of the IAD, and the Cryptogram Version (CV). 
Values in the range '00' to '9F' are reserved to avoid conflict with legacy 
Cryptogram Version Numbers. 


jba|b7/b6|b5|b4/b3|b2/b1; Meaning 
x | x | x | x Common Core IAD Format Code (FC). 
1/0]; 1 4 0 CCD Version 4.1 IAD Format (='A') 


Common Core Cryptogram Version (CV) 


CCD Version 4.1 Cryptogram Version 
(='5' for Triple DES) 


CCD Version 4.1 Cryptogram Version 
(='6' for AES) 


Table CCD 8: Common Core Identifier 
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Bits b8 - b5 of the CCI shall indicate the Format Code (FC). Values in the range 
'A' - 'F' shall indicate a CCD-specified IAD format (all values RFU by EMVCo for 
CCD). 


Bits b4 - b1 of the CCI shall indicate the Cryptogram Version (CV) for the 
Application Cryptogram. The CV indicates: 


e The cryptogram input data and key derivation method the CCD-compliant 
application uses to generate the Application Cryptogram. 


e The cryptogram input data (including CSU coding), key derivation method, 
and ARPC method the CCD-compliant application expects the issuer to use 
when generating the Authorisation Response Cryptogram. 


Values in the range '4' - 'F' shall indicate a CCD-specified cryptogram algorithm 
and data set (all values RFU by EMVCo for CCD). Values in the range '0' - '3' 
shall indicate a proprietary cryptogram algorithm. When using the CV range 

'0' - '3', applications are not CCD-compliant. 

C7.2 Issuer Application Data for Format Code ‘A’ 


The format and coding of the IAD with a Format Code of 'A' shall be as shown in 
Table CCD 9: 


Description 

Length of EMVCo-defined data in IAD. Set to '0F’. 
Common Core Identifier 
a Derivation pees Index 


9-16 Counters Contents are at the discretion of the Payment 
System. 
Length Indicator | Length of Issuer Discretionary Data field in IAD. 
Set to 'OF". 


Issuer Contents are at the discretion of the issuer. 


Discretionary 
Data 


Table CCD 9: Issuer Application Data for Format Code 'A' 


Page 206 November 2011 


EMV 4.3 Book 3 Common Core Definitions 
Application Specification 


C7.3 Card Verification Results 
The coding of the CVR for a Common Core IAD Format Code of value 'A' shall be 
as shown in Table CCD 10. 


CVR Byte 1 


ba [b7 | b6[b5/b4/b3/b2/b1| Meaning 


ma ee Application Cryptogram Type Returned in 
Second GENERATE AC 
ro [| 
ro [2 | 
Pcieor Second GENERATE AC Not Requested 


Application Cryptogram Type Returned in 
First GENERATE AC 


Issuer Authentication Failed 


Last Online Transaction Not Completed 


Table CCD 10: Card Verification Results for Format Code 'A' 
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CVR Byte 3 


Lower Offline Transaction Count Limit 
Exceeded 


Upper Offline Transaction Count Limit 
Exceeded 


1 | Issuer-discretionary bit 4 


Number of Successfully Processed Issuer 
Script Commands Containing Secure 
Messaging 


Table CCD 10: Card Verification Results for Format Code 'A', continued 
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C8 Card Status Update fora Common Core Definitions- 
Compliant Application 


The Issuer Authentication Data shall include a Card Status Update (CSU) of 
fixed length, 4 bytes long. The coding of the CSU is shown in Table CCD 11. 


CSU Byte 1 


be [b7|b6|b5]b4}b3/b2|b1| Meaning 


Proprietary Authentication Data Included 
pede 


CSU Byte 2 


Update Counters 
Hi: [0-4 Do Not Update Offline Counters 


Set Offline Counters to Upper Offline 


Limits 


Hae 208 | Reset Offline Counters to Zero 
Add Transaction to Offline Counter 


Note: The ‘CSU Created by Proxy for the Issuer’ bit shall be set in the CSU if and only if 
the CSU is generated by a proxy for the Issuer. 


Table CCD 11: Card Status Update for Cryptogram Versions '5' and '6' 
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CSU Byte 3 


jba|b7|b6[bs[b4[b3[b2[b1[ Meaning 
pofojojofojofojojRru 


CSU Byte 4 


ba |b7|b6[b5[b4[b3[b2 [bi] Meaning 


Table CCD 11: Card Status Update for Cryptogram Versions '5' and ‘6’, 
continued 


The default value for issuer-discretionary data in the CSU is zero. 


Annex D_ Transaction Log Information 


If the CCD-compliant application supports transaction logging, it shall be 
supported using the method specified in Annex D. 
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